I’ve started a little foray into using audio communication, since our team is looking into driving over the school wifi without line of sight, and I realized we’ll need audio communication.
So it comes down to this: Can NetworkTables keep up with three 2605-element DBL Numeric Arrays being updated every 100 ms?
NetworkTables has a min update interval of 0.01s. So yes.
(it’s java documentation but I assume labview NT is implemented the same way)
Thank you. Alongside a headset and a VR, this could prove to be very functional.
The LV network tables lets users determine the update rate with a parameter – always has, no limits. During beta, it was tested down to 5ms I think.
As for the robot driven with audio, you can certainly transmit pretty good audio with the equipment on the robot, but I honestly haven’t tried it through network tables. The numeric you are sending is an eight byte double, so it is way more resolution than you need. A more optimized approach would be to convert the array of numerics to I16s or even I8s, flatten to a string, and send via network tables.
But another question about the code you posted. Where is the mic? Where is the speaker? The roboRIO doesn’t have audio I/O and I don’t know that the audio VIs are going to work on it.
So if you give a bit more background, I’ll be happy to help, but I’m a bit lost in the details of what you are attempting.
Greg McKaskle
Speaker is connected to an amplifier which is connected to a DC offset removal capacitor/high pass filter which is connected to AO MXP 0.
Microphones are connected to AI 0 and 1, using a 2.5V ground-lift using a voltage splitter and a few other resistors I haven’t quite figured out.
Sounds fun.
So of course, the audio in and out will then be your own implementation based on lower level I/O. You may just want to start with a triangle or sawtooth wave generation, then play a recorded sound file, then work your way up to the full thing.
And of course this is assuming your team isn’t relying on you for more essential things, right? If not, I think this sounds like a lot of fun.
Greg McKaskle
I don’t work on this during practice, only for fun at home. And yes, it sure is a lot of fun.
Here’s an update, I set both dash and robot to convert to single-precision float before sending data to NT, robot audio code is shown in the attachment.
Audio processing print 1.pdf (205 KB)
Audio processing print 1.pdf (205 KB)
Be sure to notice that there is a red dot where the wire joins the NT subVIs. That is where a type coercion happens. NT numbers are always stored and transmitted as doubles.
The attached image shows what I was suggesting to use 1/8th the memory and transmission bandwidth. The unflatten is how you’d get the numbers back.
Greg McKaskle
Oh, so unflatten to a string and… yeah. I get it I think.
Update: Went with I16 as a format, should work pretty well. that’s 1/4 the data, right?
Here’s a snippet of my concept test code (runs on the PC). Has ~250ms of latency for some reason, buffer is only 100ms long.
I’ve attached a bit of code that does something similar to what you are wanting.
Be sure to test with headphones or you will just get feedback. With 22050 sampling rate and just hundreds of points per buffer, the delay is very small. You need to snap your fingers or make other abrupt noises to hear the delay/echo.
The notifier is an internal LV mechanism for sharing data – essentially a single element queue. Sort of like a global, but with blocking until the data arrives.
Also, when you use network tables, you can decrease the update rate from 100ms to a smaller number on the client or the server to send new data more often. You can also use the Flush operation to send data immediately after you write something important.
Greg McKaskle
What update time value would you recommend?
I think I understand the notifier and small buffer trick, but how on earth can NT work with that trick? The buffer time has to be longer than the NT update time, and NT has to send an array of string unless it can update at 22.05 kHz.
I honestly don’t know what you are trying to accomplish, so it is hard for me to say.
If you are going to lower the update period of the NT server, or going to use flush after writing the sound buffer, be sure to use the task manager or something similar to see how the network traffic looks.
Keep in mind that sound doesn’t have to be sampled at 44100, or 22050. Those standards were chosen for high fidelity music. By comparison, I think telephony transmission was 6K. Just enough to carry human voice. You may need to read the mic at 22k, but you can take every fourth byte or do similar filters to get a lower bandwidth audio signal. And you probably don’t need 16 bits of range for voice. Eight bits will probably sound fine.
I’d encourage you to start at 100ms sending audio from one computer to another using NT. Then change the period by a factor of 2 and experiment.
By the way, if you want to have a bit more control over things, you may want to consider dropping NT and just using UDP. It is actually very easy in LV. It has the advantage of dropping small packets instead of delaying and retransmitting, and has less overhead.
Greg McKaskle
