• State Resolved
  • Locked Locked
  • Replies 17 replies
  • Answers 4 answers
  • Subscribers 30 subscribers
  • Views 529 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.

AWR1642BOOST: unable to reduce the baud rate of mmwave demo visualizer GUI

Maaz Awan
Prodigy 155 points
Part Number: AWR1642BOOST
Other Parts Discussed in Thread: AWR1642

Greetings forum!

I am using mmwave demo visualizer 3.6 to visualizer data generated by AWR1642BOOST running mmwave SDK 3.6.

I am generating data on a remote location and want to observe the same on my PC at a few meters distance. I have achieved this with the help of an IoT radio link.

There is a bottleneck on the data rate that can be accomodated by the IoT device so i reduced the baud rate on the DATA_PORT and hardcoded 115200bps in the CLI.c file of out of box demo running on the device.

I can observe the data on a terminal software like hyper terminal/docklite and it is being generated perfectly even when the baudrate is as low as 38400bps for example. The GUI works fine only with 921600bps baudrate set on the mmwave device. I have bypassed the initialization validation etc as well on both sides including mmwave device as well as GUI and I can receive data on data port as soon as i turn on the radar device. However, as i reduce the data to any value below the default/recommended value of 921600bps. The GUI does not register the data frame at all. I tried debugging the application using the chrome developer options by first importing the project into GUI composer and clearly observed that although the callback function is invoked on data being received at the data port but it does not register it as a valid data. 

There are limitations on the radios being used that I cannot increase the baudrate on the radio receiver which receives the wireless data and sends over the UART beyond 115200bps.

Rest assured that I have reduced the frame periodicity to 1Hz only and I am not sending Range profile of other parameters. I am just sending detected objects information on the UART so my data frame size is normally 224 bytes per second. This data can even be handled by baud rates as low as 4800bps. 

Please guide me how to modify the GUI source code and achieve the needful. There is some timeout or some hidden check on the baudrate that i cannot seem to find in the application files, maybe somewhere in the serial

driver which is beyond the scope of my work and I dont want to waste any more time on this right now

Best Regards

Ali Awam

  • 0
    TI__Mastermind 35855 points

    Hello Ali,

    We do not support any other custom baud rate apart from the one provided in the GUI.
    However, you can refer to this thread if it helps you: (+) AWR1642BOOST: UART Baud rate - Sensors forum - Sensors - TI E2E support forums

    Regards,
    Saswat Kumar

  • 0 in reply to Saswat Kumar
    Prodigy 155 points

    Greetings Saswat!
    I am trying to reduce the baud rate...not increase it...my data size is very small and so is the frame periodicity...why should i send data at a very fast rate when the same can be done at 9600bps or 38400bps...what is wrong with you guys?

  • 0 in reply to Saswat Kumar
    Prodigy 155 points

    the thread you referred to is completely irrelevant to what i want to do...that thread wants to increase the baud rate whilst i want to reduce it...i assume you did not even read my question properly...

  • 0 in reply to Maaz Awan
    TI__Mastermind 35855 points

    Hello maaz,

    That thread refers how to modify the baud rate.
    The modification can be increasing or decreasing.
    I referred it to you for that reason.
    As stated before we do not support custom baud rate.

    Regards,
    Saswat Kumar

  • 0 in reply to Saswat Kumar
    Prodigy 155 points

    This is not a custom baud rate...this is a standard baud rate...38400bps is universally accepted as a standard baud rate

  • 0 in reply to Maaz Awan
    TI__Mastermind 35855 points

    When I say custom baud rate, I mean a value that is not 921600 which is standard for the GUI.
    The GUI can work at that speed. What I shared with you was a way to modify the application to stream at that baud rate.
    We do not support custom GUI modification on an individual basis. GUI only supports 921600. You are free to use any other form of UART receiver or plotting tools.

  • 0 in reply to Saswat Kumar
    Prodigy 155 points

    now that you have started a good discussion...i have used an intermediate software to change my baudrate from 38400 to 921600bps but still the GUI does not seem to register the data as a valid frame...

  • 0 in reply to Maaz Awan
    TI__Mastermind 35855 points

    We have tested it with this baud rate, and we do not face this issue.
    Can you compare the data you are receiving with 38400 and compare it once you have converted. Instead of radar data can you send a custom data where you can compare & decode the data?
    After converting it are you able to view it on tera term (serial port viewer) when set at 921600?
    We do not support any third-party converters. You are also able to successfully run the demo when its streaming at 921600 that means that the demo visualizer is functioning at that baud rate.
    Thats means mostly the data integrity is not there or there is some issue with your conversion tool.

  • 0 in reply to Saswat Kumar
    Prodigy 155 points

    That makes sense...if there is an issue with the data integrity then that issue is also arising from the source of the data, the mmwave sensor itself...let me compare and get back to you

    regards

  • 0 in reply to Maaz Awan
    TI__Mastermind 35855 points

    Let me know the result.

  • 0 in reply to Saswat Kumar
    Prodigy 155 points

    So i have completed the testing

    Here are my findings:
    1.There is no issue with the GUI as i have logged the same data shipped out of AWR1642 in a file as hex and then sent the same data through port binding using a serial port software(Hercules) to the mmwave GUI...the GUI was able to receive the same data and display it on baud rate of 38400bps.So there is no limitation on the baud rate other than 921600bps on the mmwave GUI. You need to upgrade your knowledge base in that aspect.

    2. The data generated from the 1642 in both baud rates, whether 38400bps or 921600bps is exactly same. I logged data in both the cases and then send the same data to mmwave GUI using the serial port software(Hercules). MMwave gui recognizes both sets of data as valid data frame and displays it without a problem.

    3. The problem lies with the how the data frame is generated by the UART driver on the AWR1642 when the baud rate is reduced to 38400bps. The data frame is being generated in bursts. The software first sends the magic word followed by packet size and metrics and then each type of packet requested by the gui or hardcoded in the mmwave firmware.

    As i understand, if i am able to generate a contiguous frame of 224 bytes, which the length in my application, without any delay between the data bytes in the frame, I should be able to receive the same on the mmwave GUI at any baud rate. Instead of using uartwritepolling function again and again, i plan to generate  single array of data and issue a single uart_write_polling when my dataframe array is orchestrated and ready to ship. For testing, i will copy the same frame generated by the radar device in my logging and testing and initialize it as an array on runtime and issue a single uart_write_polling or uart_write_blocking. Since my frame period is only 1Hz, at the end of my frame, i have plenty of time to send data at a slow baud rate.

    Hopefully i should be able to resolve this and i will get back to you soon. For the record following are the data frame for 38400bps and 921600bps:

    38400bps 

    020104030605080700000603E000000042160A00220000005AF74D8D0400000004000000000000000100000040000000C250493E9637C94000000000000000003D805ABFE1125A4100000000000000001442FC3F716EA7410000000000000000BBDD613F7EC1E14100000000000000000700000010000000E9002A03EC00A302ED006302F0000E020600000018000000703D000024C20000E7D10E00650100000D00000002000000090000001C00000000000000308200002E002E002E002E00310031003000310030002F00C832000800000000DCE10000E83D0008F41A0200

    921600bps

    020104030605080700000603E000000042160A000A0500001C68E8090400000004000000000000000100000040000000C250493E9637C94000000000000000003D80DABEEB645A4100000000000000001442FC3F716EA7410000000000000000BBDD613F7EC1E14100000000000000000700000010000000E7001703E3009C02FD003B02D1000B0206000000180000006D3D00002F0A0000EBD10E00650100000D00000002000000090000001C0000000000000069AC130030002F002F002F00320032003100310032003100C832000800000000DCE10000E83D0008F41A0200

    best regards

  • 0 in reply to Maaz Awan
    TI__Mastermind 35855 points

    Hello Maaz,

    1)

    Saswat Kumar said:
    The GUI can work at that speed.

    I had already mentioned that it can work. Please do carefully read what I had mentioned with patience. When I say support, it means that we cannot help you modify it, but you can do so if required for your use case.

    3) This is why I had mentioned you to use a sample test case to analyze the behavior so you can understand fundamentally what might be causing the issue.
    Let me know your findings.

    Regards,
    Saswat Kumar

  • 0 in reply to Saswat Kumar
    Prodigy 155 points

    Hello

    Modifying the GUI has not been a problem, I have done so already to bypass the initialization process altogether.

    The issue all this time has been on the mmwave device end.

    I will apprise you apropos my findings soon.

    Best Regards 

  • +1 in reply to Saswat Kumar
    Prodigy 155 points

    Greetings Mr Kumar!

    I have been to resolve all my issues which is why it took a while to get back to you on this.

    Apologies for the delay on my end.

    I summarize my findings as follows:

    1. The mmwave device AWR1642 firmware generates valid data at baudrates as low as 38400bps, below this value I could not generate valid data even for a frame period of 1000ms or 1Hz. 

    2. The data generation whether I used a blocking uart_write or non-blocking uart_writepolling is not contigous in terms of bytes being thrown in FIFO or UART peripheral itself. The driver is implemented as such that the there is an intrinsic delay between bytes even in a single packet. This delay is unacceptable to the mmwave demo visualizer GUI due to some underlying timeouts that I did not bother looking into by virtue of being out of the scope of my work at this moment in time.

    3. Since I am not directly receiving data generated by mmwave radar on the PC GUI over a wired medium and instead using a Datalink in between, the radio transmitter interfaced with the AWR1642 was able to buffer all the data and then transmit the whole packet to radio receiver which then delivers it to mmwave demo visualizer GUI as a single burst of contiguous data without interbyte delay. This data was decoded and processed flawlessly by the GUI @ 38400bps which was the requirement in the first place.

    4. The frame size, the TLV architecture was designed as an overkill in terms of packet size optimization as it was designed as a generic GUI for a range of devices, which is understandable. Besides, there was no checksum for data integrity. Since I only want to use it with AWR1642 with a known SDK version etc, I was able to reduce the packet size by more than 50% and also add a CRC-08 checksum for integrity of data. 

    I thank you for your patience and would like you to share my insights and working with other forum members when a similary query arises.

    Best Regards

    Maaz Ali Awan

  • 0 in reply to Saswat Kumar
    Prodigy 155 points

    Greetings Mr Kumar!

    I hope you are doing fine. I just finished what i had initially intended to do..i wanted to show you the final shape of my work. All the graphs are self-explanatory and the icing on the cake is the baud rate of 38400bps.

    Best Regards

    Ali

  • 0 in reply to Maaz Awan
    TI__Mastermind 35855 points

    Hello Ali,

    Good to know you were able to progress and finish it.

    Regards,
    Saswat Kumar

  • 0 in reply to Saswat Kumar
    Prodigy 155 points

    Thank you so kuch Mr Kumar.

    It was indeed a very good experience.

    Really had a chance to learn some new exciting aspects and I plan to publish some of my findings soon. All of this would not have been possible without Texas Instruments.

    Best Regards