Plotting of IMU, MAG, and Euler angle packets

The chosen COM port is currently hard-coded to be '/dev/ttyACM0'. Make it so that you can choose from a list of available COM ports.

To be able to figure out which board is which, you can give them IDs that will be written to the EEPROM.

"flashRecord" command will be followed by an integer number "n" that will represent the total number of samples to be recorded. Currently Step 7 in the NOR flash recorder routine sets n to the value of 1000 (20 seconds of recording at 50Hz sampling). This value should be replaced by the input argument "n".

Get the current state of the motion engine. Described as command number 2 in https://github.com/Motsai/documentation/blob/master/source/debug.md

Because it's 2015.

Take what were getting from the serial port and push it through IP to give access to cloud apps.

Make it so that you can plug the Neblina's UART to the PC and immediately start interpreting packets.

Be able to ask the board how much battery is left.

Implement finger swipe gesture interpretation

• Get Board temperature in Celsius degrees with 2 fractional decimal digits precision
• Add commands to stream the rotation and pedometer data

Implement logic described in https://github.com/Motsai/documentation/blob/master/source/led.md on the Python.

The host application on the NOR flash playback routine should be updated to report an error message, if an invalid session number is requested to be played back by the user.

Related to information in https://github.com/Motsai/colibri/issues/55

If the program throws an exception:

serial.serialutil.SerialException: could not open port 'COM16': FileNotFoundError(2, 'The system cannot find the file specified.', None, 2)

Prompt the user to enter the write COM port number. This will be especially beneficial on Windows since the COM port increments all the time.

The goal is to have the flash playback routine operate as a unit test for the UART0 data transfer as well as its primary objective of dumping the recorded data to PC. The playback process on Neblina engages UART in a high-speed packet transfer (~300Hz), which makes it crucial to evaluate the robustness of the interface. Considering the flash record routine that stores IMU data in the NOR flash, the playback routine should expect the exact same number of recorded samples all being valid IMU data packets coming from Neblina. The playback routine in Python will count the total number of valid IMU data packets that has been received during playback. This number should match the number of recorded samples.

The noisy noisy signals for the simulated IMU and MAG data are not noisy or offsetted enough,

Instead of having three different types of packets for three different files, it has all three packet types in one file. They only contain 10 Euler angle commands (0x05) and the rests are pedometer commands (0x0B). Only the yaw rotation has values: the pitch and the roll are all zeros.

When you plug an already-powered (plugged in a battery) ProMotion board in the PC, there might be junk bytes already in the buffer. The program needs be able to manage this.

Right now there are like a million files in this repo and ideally we want there to be just a few. A test folder would be good too.

There should be no mention of the details of the handshaking exchanges in the end-user application code. In our case the example application is https://github.com/Motsai/neblina-python/blob/master/neblinastream.py.

In the streaming menu, you should be able to select what kind of streaming you want or the battery level you need.

Counter and progress percentage has been added in the firmware. Need to add logic in the Python code to interpret the new data.

The command data format has been changed to include a bit in the header to indicate that it is a command rather than a response.

Motsai/colibri@99a14936406294c68afdc383e51af6bb2139b5d5

Implement debug packets such as "Switch interface"

Related to new command in Motsai/colibri#31

End-user application will use neblinaAPI.py as the API to talk to the module or ProMotion board. The goal of this is to abstract away the notion of packets and UART and deal solely with information important to the user such as quaternions, temperature, flash storage, versions, etc.

Good:

def EEPROMRead(self, readPageNumber):
     (...)
     return packet.data.dataBytes

Bad:

def EEPROMRead(self, readPageNumber):
     (...)
     return packet.data

`

When interacting with it in a shell, it sometimes just stops responding if you don't talk to it for a duration of 10-15.

Reset time stamp to multiple devices

WHen opening the serial port while the device is busy, it thros an exceptin and exits the program:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/serial/serialposix.py", line 274, in open
    self.fd = os.open(self.portstr, os.O_RDWR|os.O_NOCTTY|os.O_NONBLOCK)
OSError: [Errno 16] Device or resource busy: '/dev/ttyACM0'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "streammenu.py", line 130, in <module>
    console = StreamMenu()
  File "streammenu.py", line 22, in __init__
    self.sc = serial.Serial(port='/dev/ttyACM0',baudrate=230400)
  File "/usr/lib/python3/dist-packages/serial/serialutil.py", line 261, in __init__
    self.open()
  File "/usr/lib/python3/dist-packages/serial/serialposix.py", line 277, in open
    raise SerialException("could not open port %s: %s" % (self._port, msg))
serial.serialutil.SerialException: could not open port /dev/ttyACM0: [Errno 16] Device or resource busy: '/dev/ttyACM0'

We could make it so that the program waits for the device to become available before continuing with the execution.

Receiving a bad packet should not crash the program. Modify the try cath block inside wait for packet to try again if the exception clause is reached.

The routine checks the following:

1. Communication with the LSM9DS1 chip, by getting the temperature value
2. Communication between KL26Z and Nordic chips, by getting the firmware versions
3. The EEPROM memory: try a write, followed by a read, which must match the write data
4. Flash Recorder and motion engine's Euler/Quaternion streaming: Do a flash record and playback for both Euler angles and Quaternion data. The number of packets recorded and played back must match.
5. Communication with the power management module: Get battery level (state of charge)

For data analysis from multiple neblina nodes streaming concurrently.

Implement the Unit Test packet to test the motion engine stuff.

https://github.com/Motsai/documentation/blob/master/source/debug.md#debug---unit-test-motion-engine-data-0x04

Be able to start flash recording and playback from the python program.

Related to a feature Sunny really wanted, and it probably a feature that other customers are going to demand.

The direction angle for pedometer command seems to be of reverse byte order compared to the Euler angle command

Key error exception occurs when receiving the packets used to empty the buffers.

Pedometer packets created by neblinasim.py have a walking direction information that is out of bounds. It should stay within -180.0 and 180.0 degrees.

Attach the BluePy interface to the visualisation environment to be able to plot live streams of Neblina data on the RPi.

@osarbishei will have to check in the data.

One way to implement a timeout is to count the empty debug packets and if you receive a lot of them you can try again. We have to make sure we remove this once the medium of transmission is perfected.