Logic behind railed and not railed derivation
pluto
mars
Hi,
While playing back the logs from SD Card log in OpenBCI GUI, we could see that the stream showed railed and not railed information too, but we could not see any bit which is related for railed information in the SD Card log.
If it means railed and not railed calculation requires some logic and can be derived from the log itself, could you please tell us which part of the firmware in OpenBCI GUI is responsible for that?
Appreciate your help.
Regards,
Pluto
Comments
Pluto,
The 'railed' categorization is done purely by the OpenBCI_GUI. There is no detection of this in the ADS1299 hardware / firmware, via special 'bits' or status indications. But do note that the ADS1299 is limited to 24 signed bits of the sample values. So in some adverse conditions this maximum or minimum value hits the limit, and so this in some sense does indicate a hard-stop of the ADS1299 range. The upper / lower bounds of the signed value depends on how the channel 'gain' is set. This can be adjusted in the GUI. But in most cases the default gain of x24 works for most applications.
https://docs.openbci.com/Cyton/CytonDataFormat/
If you want to examine the GUI source code, you can find where the 'railed' status is calculated.
https://github.com/OpenBCI/OpenBCI_GUI/search?q=railed
Regards, William
Hi william,
Appreciate your respone.
Is there any python code available that derives the railed logic from data?
The most general definition of a 'railed' situation on any type of time series display, such as an oscilloscope, is that that the current signal amplitude is beyond the current maximum or minimum displayable values. It is as simple as that. See above code for what exactly the GUI is doing.
William