how to handle dropped packets? [DIY-Cyton] LabVIEW.

shadowphileshadowphile
edited June 2018 in Build-it-yourself
I have everything running with a Labview interface and it all runs great! (home built hardware)
However, sometimes the red light on the dongle will randomly blink and I get big glitches in my data that cause major havoc with my signal processing (audio feedback for meditation).
What exactly does the red light indicate and how can I detect (I assume a dropped packet) a bad one so that I can reject it before it gets into my signal path?
( I put spike-filtering in my input stream but the signal isn't quite that simple so it doesn't work very well)
Worst case I would have to do some serious mods and an isolation board so I can hook the headset directly to the PC, but that would be a major hassle.
thanks

Comments

  • wjcroftwjcroft Mount Shasta, CA
    edited May 2018
    Shadowphile, hi.

    I'm not seeing this type of behavior when I use the OpenBCI-built Cyton with BioEra in neurofeedback applications. No "big glitches", or glitches of any sort. Could this have something to do with your own build?

    I think the source for the LabView Cyton driver is available. Could you add some debug statements to catch discontinuities in the packet counter incrementing? And then print out some diagnostic info on the console port? Actually just dropping an occasional packet wouldn't cause big glitches or "major havoc". But if your dongle light is flashing / blinking, that would appear to reflect some glitch in the connectivity between the Cyton and dongle. I see no such blinks here.

    Are you running the latest firmware on all three processors?

    Regards,

    William

  • shadowphileshadowphile
    Actually I do mention that the red light blinks at the same time I get big spikes in my data that throw off running averages and such (in my application I consider that major havoc). My local wireless pollution is high though and I figured that I'm losing packets from interference.  I did not consider that a broken function considering my local radio pollution, was only trying to figure out how to identify data associated with the lost packets and interpolate the bracketing data points.
    However, I tried a median filter last night and it's working really well, even though those are not efficient.  Not a lot of testing but it seems to be working very well so far.
    thanks for the feedback though.
  • wjcroftwjcroft Mount Shasta, CA
    Have you tried changing the RFduino channels or temporarily moving your equipment to another room? Does that reduce the interference? If you are seeing the LED actually blinks off significantly long, you may be losing MANY packets, not an occasional one.
  • shadowphileshadowphile
    I have thought about moving to a wireless-signal-free location to test it out.  I will consider the channel change though if I keep having a problem.  It seems erratic; last night it ran without any streaming problems.  My environment is too saturated with bluetooth and wifi, sometimes I have had problems with real-time wireless streaming like music.
    Thanks
  • wjcroftwjcroft Mount Shasta, CA
    Another suggestion for high interference environments: use a usb extension cable to get the dongle as close as you can to the Cyton. Here is an ultra thin type cable,


  • shadowphileshadowphile
    Thanks, I never would have considered Misumi for a USB cable!
    I think I have to return to this problem because the median filter that worked was also messing with my signal data.
    Can you please describe what exactly the dongle red led indicates?  Is it when character is read from the radio, or perhaps when the radio has received a character?  I want to eliminate any software possibilities since I'm writing my own software.  I had a problem with my software's read buffer filling up and that does make the LED turn off, so I'm even sure I can assume it was due to a lost packeet (my wireless environment is noisy).
    thanks

  • shadowphileshadowphile
    ...so I'm NOT even sure I can...
  • wjcroftwjcroft Mount Shasta, CA
    The LEDs (red and green) are wired DIRECTLY to the FTDI FT231X chip (usb serial com port), Tx and Rx LED pins.



    See page 11,

    "Transmit data LED drive – pulses low when transmitting
    data via USB. See Section 7.5 for more details."

    So in other words Tx from the point of view of the FT231X, it flashes to indicate transmit over USB to the PC host.


    In normal operation it should be "buzzing" very quickly, likely at the 250 hz rate of packet reception from the Cyton. If you see any gaps in the flashes, that would likely correlate with your packet lossage.

    ----

    Have you tried the test with the thin usb M-F cable, to put the dongle right next to the Cyton? A range of thin cables is out there.

  • shadowphileshadowphile
    thanks for the detailed info, I will let you know if I trace something down.
    I'm not wearing the helmet; the board by itself is sitting next to the laptop but it doesn't seem to make a difference whether it's 2 in or 2 ft away.  It also comes and goes, which is hair-pulling!
    Should I assume that the data from the usb is pushed, not requested by the pc. (?)

  • wjcroftwjcroft Mount Shasta, CA
    When you setup your COM port, you should have set the latency to 1 ms. An entire packet comes into the RFduino over the air, then is transmitted to the serial port on the FT231X. After the final byte of the packet is received by the FT231X, the 1 ms latency timer goes off, then the buffered data is sent to the PC over usb.

    Packets come in from the RFduino every 4 ms, 250 hz.

    Are you running the latest V3 firmware?
  • wjcroftwjcroft Mount Shasta, CA
    Have you tried changing the RFduino channels or temporarily moving your equipment to another room? Does that reduce the interference?
  • shadowphileshadowphile
    Hi, I'm back after some lengthy troubleshooting.  I've dropped the latency timer to 1 ms and I am using the V3 software (everything was downloaded late last fall).
    I'm doing all my testing with the PCB unattached to anything.
    Here are some interesting facts:
    -I don't see any spikes in the OpenGUI display.  Don't know why that is.  It seems like my chart shows more raw data than the OpenBCI because if I remove all filtering and use auto-ranging I don't see any waveform on your timeline.  Maybe the spikes are there but not displaying somehow?  I'd hate to find out I'm seeing something that is always there but somehow being ignored in the OpenBCI application.
    On my own display:
    -I see the spikes, random, sometimes a few in a row, sometimes not for a while.
    -I seem them on two different laptops.
    -I see the spikes whether I'm sending a test signal or reading from the ADC or even if the channel is turned off.
    -The packet counter for the spiked data is contiguous with the surrounding packets.
    -I collected to the SD card while logging on my screen.  I'm having problems getting no files sometimes despite what seems to be quality 16gb Sandisk.  However, I finally logged a glitch on my screen and successfully logged same data to the SD card.  The spike is not on the card data.  Thank goodness it does not seem to be the ADC, replacing that would be a real pain.
    -I moved the pcb to the other side of my apartment, signal is going through 3 walls.  Still works!  I have a good radio connection.  I moved it behind a fourth wall further away and the dongle LED starts to flutter a lot, but you can't tell from the display. Dropped packets are not the issue.  However, maybe a corrupted packet?  Is there any error correction along the signal path such as in the radio protocol itself?

    I would love to try out my software against a commercial unit because otherwise it seems to be working great.
    I'm at the University of Washington in Seattle, do you have any customers here?  This is a sharing environment so I don't think anybody would mind if I approached them to do a quick test using my software since all they have to do is turn the pcb on with no probes connected. (I actually noticed somebody printing one of your helmets in our maker-space across the hall; you get around!)
  • wjcroftwjcroft Mount Shasta, CA
    I assume you test without connecting to head, for faster checks and no cleanup. But do you connect to say O2 and reference at earlobe or Fz occasionally, and see decent alpha with eyes closed? You can also short the pins for a more realistic test, to produce close to 0 uV.

    "I don't see any spikes in the OpenGUI display", So you mean your packets are coming in consistently at 250 hz (every 4 ms), everything looks good? Then I don't think you have any hardware problems. Any 'spikes' you are seeing with your LabView, might be due to glitches in the LabView packet reading routines.

    Email contact at openbci.com and ask them if they can put you in touch with a UW owner or lab.
  • wjcroftwjcroft Mount Shasta, CA
    Also, if you are using the LabView driver from @Cassani, I hope you have been in touch with him via email. You can click on his name here, then use the Message button in the upper right.


  • shadowphileshadowphile
    It works fine detecting alpha waves using the closed-eye test but all my spike troubleshooting has been with no connections the board.
    My RMS noise is sub uvolt so that looks good.
    Yes, I seem to be getting the packets and I've even examined the data at the byte level for some kind of clue but no pattern appears to me.  Radio separation did not seem to increase spike occurences.
    The spikes show up on multiple channels either alone or in sync with the other channel spikes but not neccessily with the same values. Any hardware problems at this point was thinking would have to be digital in the ucontroller or radio level.
    I figured it might be at the serial port but I'm not using a driver, just directly grabbing from the built-in serial-port modules built into Labview.  I even tried a different version of Labview!
    You do remind me that there is a different submodule in Labview that is serial but I rarely use it because it has exactly the same functionality, but perhaps the extra layer of abstraction (called 'VISA') is the problem.  Trivial to test!
    thanks a lot for your help btw
  • wjcroftwjcroft Mount Shasta, CA
    edited June 2018
    In all serial port driver situations, BUFFERING is a major consideration. If the consumer of the stream is not getting CPU processor time at the 4 ms intervals reliably, then buffering system needs adjusting. So that packets are not lost, but instead preserved so that they are grabbed when CPU is next available. 

    This is done in different ways: double buffering or circular buffering, separate threads, an interrupt service routine that runs at a higher priority stuffs into the circular buffer, etc. Any scheme must also interlock between the higher priority thread or interrupt service, and the background level that consumes the packets.

    I would suggest discussing this with @Cassani, as he is the author.


  • wjcroftwjcroft Mount Shasta, CA
    "but I'm not using a driver..." Whoa, wait, so you are not using Cassani's driver?? Why the heck not? He is likely doing the buffering correctly. Whereas your raw serial port scheme is losing packets.
  • shadowphileshadowphile
    I've done this many times before for work and personal projects.  I've got multiple circular buffers between the low level hardware buffer and the processing loop.  I WAS using the hard-coded queuing built into Labview to control the interplay between my low-level and high-level loops but I took it out thinking it was the bug, 'cept it wasn't.
    Last night I wrote a simple program that does nothing but grabs and charts the values found after decoding the packets, much faster than the 4ms rate, still get those spikes.  Not even close to filling the hardware buffer allocated by Labview when initializing the serial port (not that it was before either).  There is no way to strip down a driver anymore than that. (in Labview)
    Am I overlooking anything?  I'm open ears...
  • wjcroftwjcroft Mount Shasta, CA
    Have you tried Cassani's toolkit?? He never reported any packet dropping, and you are the first LabView user mentioning this (and not using his kit). Perhaps he is using some trick or API that you have not tried.



    Mentioning @Cassani again.

  • wjcroftwjcroft Mount Shasta, CA
    @shadowphile, hi. Did you have any luck with Cassani's toolkit?
  • shadowphileshadowphile
    Hi wjcroft.  I tried Cassani's toolkit and it didn't have a problem.  The core acquisition section was very similar to my own.  I tried dropping it into my main code but acquisition became really erratic, not sure why.
    However, now I know what the problem was.  My Labview code was corrupted.  The code looked good but broken behind the graphics.  Copying it from one laptop to another just ported over the bug as well.  When I (accidently) rewrote the acquisition section from scratch (because all my troubleshooting trashed my original code) the problem disappeared.  I have encountered weird Labview behavior like this, more so in recent times than in the past.  I used to think of Labview as reliable and crash-free.
    So..thanks for your help!  So glad this was 
Sign In or Register to comment.

© Vanilla Keystone Theme 2026