kb1lqd commented 7 years ago

Based on extension of https://github.com/FaradayRF/Faraday-Firmware/issues/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: https://github.com/kb1lqd/Faraday-Software/commit/2f42baa6360c26a6301a52f28231476f72d9be43

This is the remaining quick code I used to achieve this: https://github.com/kb1lqd/Faraday-Software/commit/8888188934376a4ba96cc9a1660410cdb41b7ef6

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 commented 7 years ago

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

kb1lqd commented 7 years ago

Update 6/12/2017

I committed https://github.com/kb1lqd/Faraday-Software/commit/273a237beaccf9ac948811a58ae46cf1d63d9870

Major updates:

Entire packet is now digitize correctly in rfdataport POST. https://github.com/kb1lqd/Faraday-Software/commit/273a237beaccf9ac948811a58ae46cf1d63d9870#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

https://github.com/kb1lqd/Faraday-Software/commit/273a237beaccf9ac948811a58ae46cf1d63d9870#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

https://github.com/kb1lqd/Faraday-Software/commit/273a237beaccf9ac948811a58ae46cf1d63d9870#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...