The blue is from data streaming over wifi. I have the Serial1 baud at 230400 feeding to a ESP8266 running a UDP server and the blue are seeing is a Node.js program running on my computer. Gonna see if I can get this up to 921600 and then we should be able to get data rates way higher.
Thanks William! I read through most of that thread, seems like there are other people interested in this too.
AJ, thanks. Would TCP be more reliable than the UDP? UDP may be a tad faster datagram delivery, but at the cost of no flow and error control.
re: with the higher baud rates it seems to be an issue of the serial clocks aligning because of the different crystal frequencies on the chipKIT and add-on board. If you can find a rate that is evenly divisible by your crystals, then serial rates will be aligned and solid. As the rates go up this becomes more and more critical. The 'default' serial rate table was derived from the old days of 300 and 600 baud modems, so the rates are just doubling factors of those. The PIC has a feature to compensate for this, but it peters out at the high baud rates. Hence you may have better luck at 1000000 bps than 921600 bps. Depending on your ESP onboard clock. See the discussion on this in Winslow's thread.
I am so new to networking that i only know how to do UDP. I think that in comparison to streaming video, we are fine with speed (gut feeling off the cusp) so TCP should ok. I need to look into how TCP works!
That's so cool about the derivation of baud rates! I had no idea!
> Hi again, William. Just seeing your most recent posts now. The first thing I did is set the latency to 3ms, and that drastically lowered the misses, but there were still a few. Then I tried 8ms, and that seems to have solved it! I NEVER would have figured that out on my own. Thank you!!!
I wonder if that is the cause for read page verification failure on OTA uploads?
Sounds like Winslow_Strong@Winslow_Strong was not able to get output from the serial1 port above 460800 baud? As I read his repo and such.
I have added code to my branch called `wifi`https://github.com/aj-ptw/OpenBCI_32bit_Library/tree/wifi which allows you to turn that external serial port on with just a simple command. "/1" to turn debug mode on which routes output to Serial1 at 115200 which "/2" sets up wifi which actually drastically changes the core functionality by no longer averaging the the daisy and always sending 16 values when possible.
Checkout this blog post from ESP8622 which references/confirms your divisor comment. Thanks so much William!
Comments
My impression is that Joel's chipkit core changes are needed to decouple from the SPI interference.
http://openbci.com/forum/index.php?p=/discussion/comment/3934/#Comment_3934
So it seems better to have this available by default, without needing any mapPps() calls in the user code.
Winslow is also using this default core mods remapping in the highspeed hardwired USB link.
http://openbci.com/forum/index.php?p=/discussion/712/prospects-for-higher-sample-rates#latest
William
http://g.recordit.co/auGbkBbrxY.gif
re: with the higher baud rates it seems to be an issue of the serial clocks aligning because of the different crystal frequencies on the chipKIT and add-on board. If you can find a rate that is evenly divisible by your crystals, then serial rates will be aligned and solid. As the rates go up this becomes more and more critical. The 'default' serial rate table was derived from the old days of 300 and 600 baud modems, so the rates are just doubling factors of those. The PIC has a feature to compensate for this, but it peters out at the high baud rates. Hence you may have better luck at 1000000 bps than 921600 bps. Depending on your ESP onboard clock. See the discussion on this in Winslow's thread.