Sampling reliability measures

Functionality, Add-ons, etc.
ole.traupe
Posts: 43
Joined: Tue Jun 17, 2014 10:50 am

Sampling reliability measures

Postby ole.traupe » Tue Sep 09, 2014 2:57 pm

Let me first state again, what a great device the BITalino is! It might solve most of our problems regarding wireless peripheral physiology for our wide-area motion capture lab.

Now, as we are planning to use it for scientific purposes, it would be very important to reliably and transparently deal with buffer overflow issues. To us there would be some good future ways to deal with this issue:

a) the option to choose between alternative behaviors of the BITalino via a flag (allow the discarding of samples: yes/no; with no eventually leading to sampling termination - the latter could be helpful for estimating Bluetooth module buffer size, or just for developing foolproof applications);
b) a sequence marker with a much larger scope (such as 12 or even 16 bit) being robustly significant over multiple seconds with respect to dropped samples, even with a 1000 Hz samplingrate
c) most preferable: an additional channel containing high-accurracy timestamps for each sample (seconds since start of sampling)

In the best of all BITalino worlds, all three measures would be combined to yield a highly fault-tolerant and interpretable bio-signal. :)

BITalino
Site Admin
Posts: 567
Joined: Tue Aug 27, 2013 3:47 pm

Re: Sampling reliability measures

Postby BITalino » Tue Sep 09, 2014 9:41 pm

Hi Ole,

Thank you very much for your preference, positive feedback, and much welcome suggestions for future improvement, which we will surely consider in the next iterations of our hardware and software ;)

For the time being, if you really need a quick fix for this:

a) Is something that you can easily implement by either editing the API or your code to produce an exception or stop the acquisition in case a sequence number gap is detected; we will however incorporate an option in OpenSignals for that.

b) You can edit our firmware to "sacrifice" one or more of the analog inputs, and use them to send a higher resolution sequence marker while preserving the same data packet structure (e.g. A0 alone grants 10-bit; A0 + A1 can give you high/low parts of a 20-bit number that can then reconstruct on post-processing).

Best regards,
The BITalino Team

ole.traupe wrote:Let me first state again, what a great device the BITalino is! It might solve most of our problems regarding wireless peripheral physiology for our wide-area motion capture lab.

Now, as we are planning to use it for scientific purposes, it would be very important to reliably and transparently deal with buffer overflow issues. To us there would be some good future ways to deal with this issue:

a) the option to choose between alternative behaviors of the BITalino via a flag (allow the discarding of samples: yes/no; with no eventually leading to sampling termination - the latter could be helpful for estimating Bluetooth module buffer size, or just for developing foolproof applications);
b) a sequence marker with a much larger scope (such as 12 or even 16 bit) being robustly significant over multiple seconds with respect to dropped samples, even with a 1000 Hz samplingrate
c) most preferable: an additional channel containing high-accurracy timestamps for each sample (seconds since start of sampling)

In the best of all BITalino worlds, all three measures would be combined to yield a highly fault-tolerant and interpretable bio-signal. :)

ole.traupe
Posts: 43
Joined: Tue Jun 17, 2014 10:50 am

Re: Sampling reliability measures

Postby ole.traupe » Wed Sep 10, 2014 7:18 am

In that case I am really looking forward to the next edition! :)

Thanks also for your valuable suggestions. I will try and have a look at the second option for now. A sample (per second) count might already provide a good level of reliability on a sufficiently efficient recording machine.

Thanks also for your quick replies!
Ole

BITalino
Site Admin
Posts: 567
Joined: Tue Aug 27, 2013 3:47 pm

Re: Sampling reliability measures

Postby BITalino » Wed Sep 10, 2014 12:49 pm

Hi Ole,

BITalino has a very precise and reliable crystal oscillator onboard to guarantee the accuracy in the sampling rate. Also related to this, but in response to your latest questions (in http://forum.bitalino.com/viewtopic.php?f=13&t=179):

- Packing a 10-bit time stamp in the data frames instead of the analog channel is indeed just a matter of programming. Note that 10-bit is the easy way... given that the data packets already have the 4-bit number as well, if you go a little bit further in your coding you can have a sequence number with up to 14-bit ;)

- Yesterday we forgot to mention, but there's actually another option you have for a more accurate clock source than the sequence number, which is use an RTC connected to the I2C pins available on the BITalino MCU, and then pack the RTC readings on the BITalino data packet structure. There are a number of I2C RTC chips with breakouts; an example is this one: https://www.sparkfun.com/products/12708

Best regards,
The BITalino Team


ole.traupe wrote:In that case I am really looking forward to the next edition! :)

Thanks also for your valuable suggestions. I will try and have a look at the second option for now. A sample (per second) count might already provide a good level of reliability on a sufficiently efficient recording machine.

Thanks also for your quick replies!
Ole

ole.traupe
Posts: 43
Joined: Tue Jun 17, 2014 10:50 am

Re: Sampling reliability measures

Postby ole.traupe » Thu Sep 11, 2014 8:00 am

Thanks for the information and suggestions!

We usually perform some kind of jitter correction on recorded data, so the clock doesn't have to be overly precise. The onboard-oscillator sounds fine to me. So I will go for the 14 bit solution for now. In most cases, we won't need the LUX channel, I think.

For starters, I tried to compile the original code on my machine (Win7 64 bit, AVR Studio 5.1) with your predefined makefile. However, the pios.h file is not found and I wasn't able to find path definitions in the makefile. I am sure I am just not reading it correctly. Could you help me out? I simply put all the files in one directory.

BITalino
Site Admin
Posts: 567
Joined: Tue Aug 27, 2013 3:47 pm

Re: Sampling reliability measures

Postby BITalino » Thu Sep 11, 2014 8:13 am

Hi Ole,

Note that A5 and A6 are 6-bit channels in the protocol when you are acquiring all 6 channels:
http://forum.bitalino.com/viewtopic.php?f=11&t=138

The LUX sensor is actually connected by default to one of these, so be sure to look into this carefully.

We'll look into the AVR Studio question and get back to you soon.

Best regards,
The BITalino Team

BITalino
Site Admin
Posts: 567
Joined: Tue Aug 27, 2013 3:47 pm

Re: Sampling reliability measures

Postby BITalino » Thu Sep 11, 2014 12:59 pm

Hi Ole,

We've tested compiling the firmware in AVR Studio from the files available on GitHub and everything seems to be working. Please try to update your AVR Studio to the latest version (6.2).

You should then check that you have the AVR toolchain installed by using AVR Studio's command prompt (accessible via Tools > Command Prompt) to execute the make command on the directory where you have the makefile.

Best regards,
The BITalino Team

ole.traupe
Posts: 43
Joined: Tue Jun 17, 2014 10:50 am

Re: Sampling reliability measures

Postby ole.traupe » Thu Sep 18, 2014 3:26 pm

Works, thank you!

Ole

ole.traupe
Posts: 43
Joined: Tue Jun 17, 2014 10:50 am

Re: Sampling reliability measures

Postby ole.traupe » Mon Aug 29, 2016 5:56 pm

So... It's been a while, but now I'm doing this. ;)

I started with an old firmware (as a memory refresher) and I more or less understand what it is doing. However, I need to wrap my head around how this part in 'live.c'


Code: Select all

*(word*)(frame+5) |= convADC10(chTable[0]) << 2;
   if (nChannels > 1)
      *(word*)(frame+4) |= convADC10(chTable[1]);
   if (nChannels > 2)
      *(word*)(frame+2) |= convADC10(chTable[2]) << 6;
   if (nChannels > 3)
      *(word*)(frame+1) |= convADC10(chTable[3]) << 4;
   if (nChannels > 4)
      *(word*)frame |= (convADC10(chTable[4]) & 0x3F0) << 2;
   if (nChannels > 5)
      frame[0] |= convADC10(chTable[5]) >> 4;
     



Corresponds to the frame description posted here:

viewtopic.php?f=11&t=138

I did this for hours now and my brain hurts. Could somebody perhaps walk me though the first two if statements to show me how the bits get aligned?

Thanks a lot!

ole.traupe
Posts: 43
Joined: Tue Jun 17, 2014 10:50 am

Re: Sampling reliability measures

Postby ole.traupe » Tue Aug 30, 2016 9:03 am

Or let me ask more directly: do these lines add up to the frame layout graphics from the link, or do they create a different layout?


Return to “Features”