• State
  • Locked Locked
  • Replies 34 replies
  • Subscribers 34 subscribers
  • Views 2636 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Presentation due friday; TM4C serial infrared is 50% functional. Please help!

Erik A
Intellectual 540 points

Good Afternoon,

I am going to zip two text documents and attach them here. One titled base station, one titled data collector.

The data collector samples temperature from the ADC and stores them in flash. Then, the user can open putty (connected to the base station) and press 't' in order to transmit the temperature values from data collector to the base station.
I actually use a MATLAB gui that mimics the same functionality and receives the transmitted data and plots it.


All of this works with a physical tx & rx connection on UART1 between the boards. If I use UARTEnableSIR(UART1_BASE, true); the following occurs:
I can transmit the user choice from the base station to the data collector. The data collector DOES receive it and handles the choice accordingly. However, when the temperatures are sent back to the base station (and to the gui) I receive NO values. Again, this does work with a physical connection...but breaks with the simple inclusion of uartenablesir.


I would GREATLY appreciate it if someone could run through the two iterations of code and see if I am missing something that would cause the infrared not to work. I am to present this Friday. I have an older iteration of code(continuous data transfer) that works...so I know it is software related. I just don't know what is wrong.


Thank you!!!for_debugging.zip

  • 0
    Intellectual 540 points
    Also, while I am at it...I would like to loop back to CheckUserInput() after I receive ALL of the data values. If I tried to put it inside of the while loop(at the end of main), I can't receive any data at all.

    I may have one more question tomorrow depending how I make out with things.

    Thanks again!!
  • 0 in reply to Erik A
    Intellectual 540 points
    I would like to add a boolean or integer to my message structure. I could set this to "true" when we are in our last loop of data transmission. However, I've tried a couple of things and I am struggling with the implementation. A hand with this would be terrific.
  • 0
    TI__Guru**** 244400 points
    Hello Erik

    Tall order on a short time notice.

    What does the Base Station receive. You may want to check it at the output of the IR receiver!!!

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Intellectual 540 points

    Hello,

    Totally understood. Any help is certainly appreciated but I get it if there isn't enough time.

    The base station receives nothing when used with infrared. Without infrared it receives the temperature samples that were collected. In terms of checking the output of the receiver what exactly would I be doing?

    I know the hardware is fine and I know the code is functional. But the uartenablesir messes it all up for some reason.

    Thanks for the speedy reply Amit I really appreciate it.

  • 0 in reply to Erik A
    Guru 47900 points

    Erik A said:
    I know the hardware is fine and I know the code is functional

    That is (so often) the claim yet (so rarely) proves the case!

    We're not told about the separation (distance) between IR TX & IR RX - are we?

    And what about "beam aiming" and/or potential obstructions?   (to include sunlight, or room ambient, or interference from fluorescent lighting)

    Your claim of "hardware being fine" only proves true if your physical, hardware setup remains (absolutely) unchanged - and you are able to quickly switch the controlling software between "works & fails."

    Assuming that your hardware "does" meet the above specification - your issue (likely) moves to IR TX and/or IR RX.  Have you a duplicate hardware set-up?   Building (just) one is extremely risky - having multiple, identical units - which enables A vs B vs C testing - has saved many.  (this reporter, included)

    You should be able to measure the input signal to the IR TX - you should compare/contrast noting any difference between IR TX input, signal levels.   If there is a difference in input signal - the output (may) be reduced - or lost entirely.   If the IR TX performs - you need to repeat such "comparison testing" upon IR RX's output.   Any change between "works & fails" should be noted.   Your objective is to coax the same signal levels during "works and (past) failed!"

    Only when performing testing w/this level of rigor can your hardware (really be known) to be "fine."

  • 0 in reply to Erik A
    TI__Guru**** 244400 points
    Hello Erik

    What is the IR front end device you are using?

    Regards
    Amit
  • 0 in reply to cb1
    Guru 27665 points
    cb1's right you do need to check at the HW level, if only to find out where the failure may occur.

    One other thing, A hardwired connection will work in full-duplex. I'm not sure that an IR connection can

    Robert
  • 0 in reply to Robert Adsett
    Intellectual 540 points

    Thank you for the input.

    You are right, I can't say for sure there are no issues. I do have a duplicate setup and it has exactly the same issue. The distance and angle remain the same between older iterations(non duplex) and my current code. I can certainly break out an oscilloscope tonight and check things out. The device I am using is a vishay tfbs4650.

    How would I determine if it works full duplex or not? The device has an Rx and TX node...would it be a software limitation?

    That would be huge If we can prove it one way or another.

    I can provide more details on my computer after work, thanks for the replies thus far!

  • 0 in reply to Erik A
    Guru 47900 points
    The imposition of the IRs (both TX & RX) will delay the signal edge arrivals AND prolong the signal edge departures. And - as you have (both) TX & RX delays - at high speeds you are MOST vulnerable.

    Thus slowing your baud rate - on both ends - should be a CERTAIN first step.

    Duplex enables simultaneous TX & RX - I believe both (friend Robert) & I are (very) much against that. Simplex has proven quite, "Good for Gov't Work!" Should you see (both) simultaneous signal activity on RX & TX - that's duplex. RX or TX (alone) is Simplex - you've NO NEED for Duplex! (unless your goal is pain/suffering...)
  • 0 in reply to Erik A
    Guru 27665 points
    Full duplex, both sides can transmit simultaneously
    Half duplex, each side must take turns (and wait for the other side to finish before starting it's own transmission).

    Full duplex is a lot easier to deal with since there does not need to be a way to determine whose turn it is. For half duplex your protocol must have a built in method for determining which side can transmit.

    A half duplex protocol will run on a full duplex link without any changes. A full duplex protocol will need a complete reworking to run on a half duplex link.

    The issue with IR is the local transmitter outgoing signal will feed back into the receiver. There may be ways around that using multiple modulations but I don't know that any IR transceivers use that. So I would expect that most (maybe all) IR protocols are inherently half duplex.

    Robert

    I do seem to recall that there was an IR based room LAN that used spread spectrum techniques that would probably allow multiple transmitters but that's leagues away from what you are doing.
  • 0 in reply to Robert Adsett
    TI__Guru**** 244400 points
    Hello Erik,

    Since the base station does the transmit and data is received by the end node, it would be important to check (and as per what Robert indicated) that the base station may also be receiving this energy and would be writing to the receive FIFO. The IrDA spec mentions that a 10ms time has to be given between transfers so that the Bias on the Analog IR front end decays due to the previous transaction.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Intellectual 540 points

    Hello,

    Thank you for the breakdown Amit and also for the further replies everyone. I am working on the code now and will start by slowing the baud rate. I will also add a delay between the user input and the transmission back to the base station. Hopefully one of these two work!


    ...I will post my results shortly.

    Thanks again

  • 0 in reply to Amit Ashara
    Intellectual 540 points
    Hello again,
    I changed my baud rate from 9600 to 2400 and included the following delay. Neither resolved the issue. I did pick an extra large delay for the fun of it. DataHandler sends out data immediately after a t is received so I figured this was a good place to put it.

    My command (sending 't') works fine from base station TX to data collector RX. The base station then goes into the while(true) loop expecting values. <I still want to change this, but one thing at a time>. So it SHOULD work.

    Any other ideas?

    Thanks!

    void CheckUserInput(){
    char received;
    while(true){
    GPIOPinWrite(GPIO_PORTA_BASE,GPIO_PIN_2, 0x00); //turn off printed board led
    received = UARTCharGet(UART1_BASE);
    SysCtlDelay(6000000); <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
    if(received == 'c'){
    UARTprintf("\nErasing memory now...");
    FlashErase(0x10000);
    index = 0;
    GPIOPinWrite(GPIO_PORTF_BASE,GPIO_PIN_1|GPIO_PIN_2|GPIO_PIN_3, 0x04); //Blue LED
    SysCtlDelay(6000000);
    UARTprintf("\nMemory erase complete!");
    } else if(received == 't'){
    UARTprintf("\nBeginning transmission now...");
    DataHandler();
    UARTprintf("\nTransmission Complete!");
  • 0 in reply to Erik A
    TI__Guru**** 244400 points
    Hello Erik

    After the transmission from Base Station did you check if the UART receive FIFO had any data on the Base Station?

    Did you connect a scope and check if the IR-AFE sends out any data to the UART RX pin on the base station?

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Intellectual 540 points
    After I choose 't' to receive the data back.. the program hits inside each of these loops:

    // The receive timeout interrupt fires when you have received bytes in your FIFO but have not
    // gotten enough to fire your Rx interrupt. This is because the FIFO level select determines when that
    // interrupt goes off.
    if((intStatus & UART_INT_RT) == UART_INT_RT)
    {
    // While there are bytes to read and there is space in the FIFO.
    while(UARTCharsAvail(UART1_BASE) && RingBufFull(&rxRingBuf) == false)
    {
    // Write a byte straight from the hardware FIFO into our Rx FIFO for processing later.
    RingBufWriteOne(&rxRingBuf, (uint8_t)UARTCharGet(UART1_BASE));
    }
    }

    // The Rx interrupt fires when there are more than the fifo level select bytes in the FIFO.
    if((intStatus & UART_INT_RX) == UART_INT_RX)
    {
    // While there are bytes to read and there is space in the FIFO.
    while(UARTCharsAvail(UART1_BASE) && RingBufFull(&rxRingBuf) == false)
    {
    // Write a byte straight from the hardware FIFO into our Rx FIFO for processing later.
    RingBufWriteOne(&rxRingBuf, (uint8_t)UARTCharGet(UART1_BASE));
    }
    }

    Afterwords it goes down to the while(true) loop and bounces back and forth between
    while(true)
    {
    //Check if we have received some bytes.
    if(RingBufEmpty(&rxRingBuf) == false)
    {
    // Did we receive enough bytes that it could be a message? In the real world you
    // need more complicated logic for multiple messages but this works for now.
    if(RingBufUsed(&rxRingBuf) == sizeof(message_t))
    {
    But it never goes inside the inner IF statement and thus I don't receive anything. I don't have a full understanding of how these are all related so I can't provide any detailed analysis.

    I have not checked with a scope yet, I will do so in a bit. What is the AFE in the IR-AFE acronym? I planned on putting a scope on the data collector TX and a scope on the base station RX to see if I get the same data. I will need a second pair of hands to accomplish this though.
  • 0 in reply to Erik A
    TI__Guru**** 244400 points
    Hello Erik

    IR-AFE = Infra Red Analog Front End

    I would suggest first checking Base Station TX, Collector RX: then Collector TX and Base Station RX: and then Base Station TX and Base Station RX for the same transmitted 't'

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Intellectual 540 points
    Sure, I will definitely do this.

    Via debugging and from the resulting actions, 't' from base station TX to data collector RX should show on the scope as expected. It will be interesting to see the following two combos.

    I will either post information or pictures for each. Awaiting arrival of my partner.

    In the meantime,
    The while(true) loop. How can I exit this and go to CheckUserInput()? As of right now I would rather have a fully functioning system without infrared if that is what it comes down to.
    I wanted to put a boolean in the msg structure on data collector/base station but I wasn't able to receive my temperature values after my attempts.

    I really appreciate your help! After friday I hope to continue this project for my own learning benefit but I will not have any deadlines/requirements to meet.
  • 0 in reply to Amit Ashara
    Intellectual 540 points
    Hello. I put a scope on base station TX and data collector RX.
    What I noticed was the 't' outgoing from base station TX and received on data collector RX
    ...but then I noticed the data also on the data collector RX.
    So it seems that you were right...there is "contamination"

    I then did data collector tx and rx. The rx receives 't'...the tx spits out the data and then the rx is seeing it...

    I am going to double...and then triple my delay. See if this helps any.

    Thoughts? Suggestions?
  • 0 in reply to Erik A
    Intellectual 540 points
    With that said...
    I checked base station RX
    & data collector TX

    The data DOES in fact get back to the base station. Why am I not seeing it in my code/putty?

    Thanks
  • 0 in reply to Erik A
    Guru 10570 points
    If you've a spare output bit toggle it in your receive interrupt. That will help you determine if your characters are being received. Then you know if you should look next at your processing or the UART setup.

    Robert

    BTW, the transmitter receiving what it is sending is typical of half duplex setups unless the receive is explicitly turned off. It can be useful for error checking. When you think about it, is hardly surprising that a light sensor would pick up the light source directly beside it.
  • 0 in reply to Erik A
    Intellectual 540 points

    This video depicts base station RX on left. Data collector TX on right

    We can see the OUTGOING 't' on the base station RX. We then see the OUTGOING data on both the data collector tx(right) and base station rx(left).

    I did put a delay between base station receiving a character and base station receiving data in the while(true) loop.


    ..I also had a delay between data collector receiving the character and then transmitting the data.

    Both delays were AFTER the videos were made. I did not get anything received in putty.

  • 0 in reply to Erik A
    Intellectual 540 points

    Base station rx on left. Base station tx on right

  • 0 in reply to Erik A
    Guru 10570 points
    Video doesn't play here. A snapshot or two might work better. Before considering that though I'd look at the receive bit toggle I suggested earlier.

    Robert
  • 0 in reply to Robert Adsett72
    Intellectual 540 points
    Thank you for the reply Robert.

    Can you please expand a bit on the spare output bit in the receive interrupt? I'm not quite sure I follow/understand how to accomplish that.

    Thank you thank you!
  • 0 in reply to Robert Adsett72
    Intellectual 540 points

    1745 is the first video I posted about

    IMG_1745.zip

  • 0 in reply to Erik A
    Guru 10570 points
    The simplest technique is to set an output high on interrupt entry and low on exit.

    That simple toggle gives you a lot of information. Most importantly for you now it tells you if your interrupt is occurring. One of the most important troubleshooting techniques is cutting the problem in two.

    Robert

    BTW, I don't download files
  • 0 in reply to Robert Adsett72
    Intellectual 540 points
    Understood, I don't blame you.

    I imagine an LED on and off will accomplish the same thing. I will attempt this before I leave tonight. Certainly a good idea.

    With what I said to Amit earlier, I did debug the base station and I did get to the interrupt once the data was sent and received. Therefore I would imagine the LED will I'm fact turn on. I will still try it though.
  • 0 in reply to Erik A
    Guru 10570 points
    If you're in the interrupt long enough to see an LED flash that's already an indication something is wrong. The interrupt shouldn't be long enough for your eye to register.

    Robert

    Part of the purpose for doing this is to verify what you think is operating correctly actually shows evidence of doing so. If it does then you can check your later processing.
  • 0 in reply to Robert Adsett72
    Guru 10570 points
    You've already made progress that way tonight. You've eliminated, or nearly so transmission The base, reception at the remote, transmission from the remote and physical reception at the base. Don't knock the progress you've made.

    Robert
  • 0 in reply to Robert Adsett72
    Intellectual 540 points
    I appreciate the support!

    I am attempting to fix another issue(sending a float to a string in code composer as we don't have sprintf capability) so I think I will try this high pin tomorrow with an oscilloscope. However, I do need to tackle the powerpoint for my presentation. Hopefully I can get to everything tomorrow night and I will post back and other information I have.

    I am not too confident that I will get this working by friday(purely my fault for not asking sooner)...but I'll keep trying as long as I have help.

    Thanks again to all of you!
  • 0 in reply to Erik A
    TI__Guru**** 244400 points
    Hello Erik,

    Don't complicate by adding float yet.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Guru 47900 points
    Re: "Don't complicate by adding float, yet!"

    Yes, yes, yes. You can do the "PPT" anytime (and on your time) - you should make every effort to follow the direction given here - it's quite rare & you cannot expect "it" to last forever...
  • 0 in reply to Erik A
    Guru 55913 points
    Hi Eric,

    Many IR systems use FSK modems in half duplex like Robert mentions earlier. FSK modems use phase lock loops with a low pass filter to lock on to a high or low frequency derived around a center frequency Cfo in the low pass filter. (Frequency Shift Keying).

    That is why you may getting IR cross talk -- One of the modem sets low pass filter Cfo must be higher or lower than the other modem sets. A possible alternative is to use fiber optic cables (Maybe Radio Shack) and black electrical tape to test the IR parts are actually working without having FSK cross talk. Typically to change the Cfo we have to fire him and hire a new Cfo replace the R/C values in the phase lock.

    Others here may be a help to determine values and or set the Cfo's of the modem pairs given schematics. Fiber optic cables will get it to class and perhaps an A+ to boot.