Send Digitized Audio - RFDataport

[kb1lqd]

Based on extension of FaradayRF/Faraday-Firmware#75

@kb1lqc @reillyeon @jbemenheiser @el-iso

I've committed a quick commit that ties stdin and stdout from the OPUS audio codec to faraday transmit. I notice the transmit is stuttering a lot and I'm not sure why. Eventually the transmissions quite and I believe a background process fails, maybe a datatype bug. All in all I do get some data over. I used proxy logging to see what gets into the proxy for transmissions as I suspect maybe we are overflowing if pushing batches too fast?

I know audio is able to encode and decode as I successfully piped it from the TX to RX program in linux.

I also know that I can get Faraday to TRANSMIT audio frames but I am not sure how many are getting through even TX due to "stuttering" I'm observing in the packet transmissions.

This commit contains the first push of a proxy log with me talking while transmitting: kb1lqd@2f42baa

This is the remaining quick code I used to achieve this: kb1lqd@8888188

Using the proxy logging functionality I see only about 101 packets which is lower than I'd expect. I need to decode these and see their counts/quality.
This is just a print of the recieved data INTO proxy:

Also Proxy log is kinda of annoying into that this data definitely came in a lot faster but at a "rate" of 1 is plays one entry per second... this should replay much faster unless something else weird is going on.

[kb1lqc]

Yeah procy log was a quick fix to get 1hz data. Definitely can upgrade it to get faster rates

[kb1lqd]

Update 6/12/2017

I committed kb1lqd@273a237

Major updates:

• Entire packet is now digitize correctly in rfdataport POST. kb1lqd@273a237#diff-c3e3f3e0b410bef86b7e9889ed37cbd2R36
• Updated interval test python script to output STDOUT instead of direct POST.
  • This allows most identical testing of the audio with random data.

OPUS | tx.py | faraday_rfdataport_audio.py

The 3 program pipe above produced the following video:

https://www.youtube.com/watch?v=BikyiKCJGUg&feature=youtu.be

• The stuttering is greatly reduced after updating the packet to BASE64 the entire packet
• The remaining "sticato" sound is bursts of 3 packets during each packet transmission.
• The transmissions stop after a duration of time

OPUS | faraday_rfdataport_audio.py

Removing the unneeded tx.py produced nearly identical results as the previous test.

interval_tx_test.py | faraday_rfdataport_audio.py

kb1lqd@273a237#diff-6ee102ea078213221cc22ea66c3585c2R51

This test removed the audio encoding and produced random data for the server to consume through STDOUT. This produced the same results as the above tests and would randomly stop. I changed the interval of transmissions to play with potential buffer overflowing and the server stopped even with a single transmission every 500ms.

interval_tx_test.py POST into RFdataport Server

kb1lqd@273a237#diff-6ee102ea078213221cc22ea66c3585c2R50

directly POST'ing data into the server produced the same results and the server eventually stopped.

Review

I believe we have a problem somewhere deep in proxy, UART, or the RFdataport server. All in all proxy produces little information to check for overflows or missed data. @kb1lqc I think we should sit down and make sure we look over proxy and add basic debugging tools as needed. I know from prior testing I barely touch the MSP430 packet buffers. I can check again but this doesn't explain why PROXY must be reset after the transmissions stop...

[kb1lqc]

Sounds like a plan!