I’ve been working hard to make IdeasX deployable for testing in a real world environment. I’ve also be cleaning up the code based to make it easier for others to hopefully join in on the fun. Attached is the user-manual for the IdeasX Alpha.
If you believe you’d be interested in helping or have potential users please don’t be afraid to contact me.
It’s been quite a while since I’ve seriously worked on or written anything about IdeasX. The project has been placed on hold for a few months now. I’ve recently graduated school and I’ve been working on a few things in my personal life. I’ve decided to dedicate a few hours each week to the project to see where it will go. My time is limited thou as I need to spend slightly less than 24×7 hours behind a laptop screen.
I’ve causally and not so casually made a few decisions during my hiatus:
I would like to switch the IdeasX embedded devices to an RTOS platform. MCU are going to continue to embedded multiple processors and radios. I’m confident all future embedded devices will be running a scheduler / RTOS (for better or worst). Porting to an RTOS will simplify code development, and teach me a few new skills. This way I can keep up with my jack of all trades master of none.
If I’m going to be spending only a few hours a week doing development, I need to be developing on a platform that allows me to actually get things done. A polished development environment which will give me debugging capabilities and quality code.
The ESP8266 is not exactly the ideal solution to this. There is a FreeRTOS SDK, but the debugging features of the device are not well documented.
I’ve managed to develop a sketchy makefile / shell script setup which permits me to do basic debugging with a GDBstub and compile with FreeRTOS. I still need to develop / port a MQTT library to RTOS. Unfortunately, not all the SDK commands for the ESP8266 are available in the FreeRTOS SDK. Porting and testing is also … really really un-fun.
I’ve been considering using a part from the TI SimpleLink line: ideally, the CC3220. The SimpleLink line is completely code portable (in theory), and I’m required to learn it for work anyway. The sad bit is the chip costs more than the entire ESP8266 with a flash chip, all the RF components, and a shield.
I’m been working on a debug mode for the IdeasX v0.3.1 sensor module to send back live accelerometer (XL) and gyroscope (G) from the LSM6DS3. The idea is to have the encoder send data back to a computer to be remotely processed. (The final design will have the module locally processing the data every 100ms.) The purpose of this is two fold:
It will permit me to rapidly develop and deploy different gesture recognition / motion detection algorithms using a high level language such as Octave or Python before deploying them on the module.
The methods developed for streaming data can later be used for training applications. Example: if a significant motion algorithm is selected to activate an actuator, an initial configuration dialog will stream the data back allowing the therapist to see the range in XL and G values. The therapist would then adjust the thresholds for significant motion according to the range in values of the data streamed back.
Design / Guesswork
The LSM6DS3 utilized by the V0.3.1 module contains a 8kB FIFO which can be used to store information generated by the device (accelerometer, gyroscope, and temperature). When raw IMU data is going to be used for adaptive switching, the FIFO will permit the ESP8266 to process the data in chunks freeing up processing time for other operations.
The normal order of operations would be some like what follows:
Set the IMU to the desired sampling rate.
Configure the FIFO to trigger an interrupt on INT1 when the desired number of samples is reached.
When the interrupt is triggered, the ESP8266 will dump the specified number of samples used for the sense period.
The ESP8266 will process the data by applying a detection algorithm (NN, DTW, etc)
If the detection algorithm has detected an event, the ESP8266 sends a Data Message through the IdeasX system.
For streaming information, the following debug order of operations is proposed:
Set the IMU to the desired sampling rate.
Configure the FIFO to trigger an interrupt on INT1 when the desired number of samples is reached.
When the interrupt is triggered, the ESP8266 will dump the specified number of samples used for the sense period.
Repeat step 3 for X number of times then proceed to 4
The ESP8266 sends the raw data via a Data Message through the IdeasX system.
Due to limited FIFO size and various sampling rates, a few plots were generated to determine the number of samples which would be accrued over 4 different proposed sampling periods (50ms, 100ms, 150ms, 200ms). “Sampling period” here refers the amount of time the LSM6DS is allowed to accrue samples before being dumped.
Figure 1: Samples vs ODR
The first figure displays the number of samples accrued based on the sampling rate of the IMU or output data rate (ODR) and the length of time samples are allowed to accrue. It should be noted each sample is actually 12 bytes total. Each axis for the accelerometer or gyro is represented by two bytes. The resolution can be reduced to 1 byte per axis. As the response time of the module should be <200ms, a 200ms sampling period can be ruled out as too long.
Figure 2: Time required to dump FIFO based on ODR.
Figure 2 displays the amount of time required to dump the FIFO. This was based on experiments which recorded the amount of time required to dump a single sample from the IMU and store that sample in RAM.
Figure 3: It requires 8us to receive 32bits from the SPI port and to store it into an array.
Figure 4 displays the number of bytes the LSM6DS3 will attempt to store in the FIFO based on the 4 evaluation periods. The black horizontal line represents the limit of the 8kB FIFO. The simulation assumes the gyro and xl are both storing samples for each axis with full resolution (16 bits).
Figure 4: Bytes!
Implementation
The v0.3.1 module required a tiny modification. A jumper needed to be soldered to attached INT1 to PBA. This also required a modification to the GPIO ISR routine to check if the interrupt was triggered by the LSM6DS3 or the pushbutton. Basically, the ESP12 has NO GPIO lines. I had to double up functionality.
Figure 5: I soldered a 0R resistor to R33 shorting PB_Ax to INT1
The final settings had the LSM6DS3 sampling at 208Hz. The ESP8266 would dump the FIFO every 100ms and store it into a buffer. This would repeat 10 times and then I simply dumped the buffer into an MQTT message instead of first formatting it for a Protobuff. Note…this was a feasibility test. I modified the ideaX-sniffer tool to plot the data using Qt. You can see a short screen capture of me plotting the data here.
Figure 6: Plotting XL data from v0.3.1 module over WeeeeFeeeee (Wi-Fi).
There is much that needs to be done to make this viable. The data needs to be packaged. There needs to be additional commands made to set the sampling rate of the XL and G remotely along with the threshold of the FIFO to trigger an interrupt. It might be easier to simply make a command to send byte X to address Y out of the SPI bus. The ideasX-sniffer tool also needs to be updated of course to support the new commands, but luckily that is super easy : D.
…then the fun with signal processing begins (muhaha, j.k. I have no idea what I’m doing.)
This morning I visited my favorite coffee shop and decided to fool around with my RTL-SDR T.V. tuner. I’ve used it once before to decode the information sent via my car’s fob. At the time, I was interested in attempting to crack how the “code” sent to my car was encoded, but I was quickly discouraged by the level of encryption. Jamming the TX to a car and then replaying it later is a much more effective method.
This morning I was simply exploring the functionality of it again in preparation for spurious signal detection on a job site later in the week. I loaded up GQRX and took a look around 900MHz and I found a few cool FM signals.
Here you can see what I believe is FSK signal at 930MHz. I recored the audio using a narrow-band FM demodulator and opened it in Audacity to see if I could see any data / preambles / or sync periods for the receiver. Amazingly, I could!
Here you can see what a believe is a preamble followed by a sync period for the receivers clock. Pretty wild! I’ll zoom into the data right after the sync period now.
The preamble appears to have a period of 27ms which is approx. 37Hz followed by the sync period which is 1-2ms (audacity isn’t really built for this and isn’t giving a ton of resolution). This means the data is being clocked at around 1 – 0.5 kHz. Not blazing fast by any means.
Interestingly, this is later followed by a sync period with an identical clock and then another which appears to double the clock. I’m guessing the transmitter sends some basic information at a low data rate for receiver’s with a crappy RSSI and then additional information for those with a decent RSSI value.
I decided to extend the clock through out the signal w/ Pinta (the Linux version of paint) to see if I could determine the encoding scheme (NRZ, Manchester, etc). As expected, I literally have no idea what I’m doing and extending th clock didn’t really reveal anything to me. I would expect the data to sampled on either the rising or falling edge, but appears to be needed on both edges for to detect some of edge transitions. Manchester / Bi-phase is kinda outta the question right away based on the length of some of the pulses.
I think when I get some time and I’m tired of IdeasX, I’ll build a receiver in GNUradio which will sync sampling based on the edge transitions, examine common encoding techniques, and then bust this thing. I tried to open an existing NFM receiver design, but it appears to be using some dated blocks.
If you follow me on anytype social media, you’ve likely seen some bizarre pictures with wires and scrolling code. I’m hoping it instilled feelings of awesomeness and confusion, like those (got milk?) commercials which vanished into the ether in the late 90s. Anyway, to the pointy bit, I’ve been developing a system designed to connect severely disabled students with C.P. to computers and other electronic devices (AKA the Ironman suit I’m after hours at work, shhh).
The original picture of me was rated PG-13 sooo
If you’d like to understand what the hubbub is about, how it works, and why I’m doing it or maybe just make fun of my spelling, feel free to checkout the IdeasX pages on this website. (Only one page is completed)
If you find any of this interesting and would like to join forces or if you happen to find my explanations particularly confusing, feel free to contact me!
Here you can see what I believe is FSK signal at 930MHz. I recored the audio using a narrow-band FM demodulator and opened it in Audacity to see if I could see any data / preambles / or sync periods for the receiver. Amazingly, I could!
