SET_REPEAT:0x01::D command not working

[davidvondle]

I have programmed the dongle and coins with the most recent code. If open a terminal to get a datastream from one of the coins using:
:1 :START_RTC SET_REPEAT:0x01::D
it runs for <1 second then stops.
I can send another command to get it to run again, but this time the yaw,roll,and 3 euler angles respond with NaN.

[zrecore]

Reproduced the issue. I'll have a look on Monday. Thank you for filling the issue here.

[drogge]

Took a look at the FemtoCore source and to be honest couldn't figure out how repeat commands are repeated. Unless it's done by sending the command over the network again. One thing that looks kind of sketchy is the use of static buffers in a lot of the functions. If any of the code gets reentered the buffers could overflow. This may eventually lead to _data_flow_command overflowing into kFilters or something. No hardware to test things on. Good luck.

[zrecore]

Took a look at the FemtoCore source and to be honest couldn't figure out how repeat commands are repeated. Unless it's done by sending the command over the network again. One thing that looks kind of sketchy is the use of static buffers in a lot of the functions. If any of the code gets reentered the buffers could overflow. This may eventually lead to _data_flow_command overflowing into kFilters or something. No hardware to test things on. Good luck.

The "SET_REPEAT" command runs on the dongle, and re-issues the supplied command once a response is received.

:1
:START_RTC
SET_REPEAT:0x01::D

@drogge ping me via e-mail or twitter (support@femtoduino.com), I can get you some test hardware.

[drogge]

I'm having a bit recreating this bug. However I will admit that I have recompiled the source obtained from download.femtoduino.com. The closest I've come to it is having the dongle quit reporting results from the coin D command. One this of note is that the led on the coin is red. From the FemtoCore.cpp source this means that NWK_DataReq yielded a NWK_PHY_NO_ACK_STATUS status.
The coin starts reporting correct results if the SET_REPEAT:0x01::D command is re-issued on the dongle.

I think that the NaN's reported on the original bug report is because the IMU got reset somehow. Either that or the coin reset it self.

[drogge]

Looking further, it seems there's a time element involved with FreeIMU. For example if, through the Arduino serial monitor, I init the IMU with the '1' command and immediately display the IMU results with the 'D' command I get reasonable results:

1:OK298908,-2.9625,0.0255,0.1797,359.5229,1.4689,349.7203,-1.1646,1.1419,1.2877
300122,-2.9067,0.0036,0.1924,336.7409,0.1701,348.8600,-0.3685,0.3536,0.7139
300919,-2.5070,-0.0510,0.1880,294.7010,349.3136,350.3329,0.5123,-0.5187,0.0764
301634,-2.4459,-0.1832,0.1798,257.0276,348.0993,350.6876,1.2414,-1.2408,-0.4516

Even if I init the IMU and wait 10 seconds I still get a good reading:

1:OK857198,-2.6292,0.0000,0.0000,359.1136,0.0000,-0.0000,1.4589,-1.4561,-0.6125

However if I wait another 10 seconds I get an invalid reading with NaN's:

866219,-2.5751,nan,nan,nan,nan,nan,0.5479,-0.5540,0.0426

I now think that what's happening in the original bug report is that some network error causes the coin to either not send a response to the D command or the dongle to miss the response from the coin. Then if you wait too long before restarting the SET_REPEAT command the coin's IMU will time out and start yielding NaNs.

The time sensitive code in the FreeIMU code seems to be these lines in function FreeIMU::getQ(float * q, float * val) in FreeIMU.cpp:

now = micros();
sampleFreq = 1.0 / ((now - lastUpdate) / 1000000.0);
lastUpdate = now;

[zrecore]

Looking further, it seems there's a time element involved with FreeIMU. For example if, through the Arduino serial monitor, I init the IMU with the '1' command and immediately display the IMU results with the 'D' command I get reasonable results:

1:OK298908,-2.9625,0.0255,0.1797,359.5229,1.4689,349.7203,-1.1646,1.1419,1.2877
300122,-2.9067,0.0036,0.1924,336.7409,0.1701,348.8600,-0.3685,0.3536,0.7139
300919,-2.5070,-0.0510,0.1880,294.7010,349.3136,350.3329,0.5123,-0.5187,0.0764
301634,-2.4459,-0.1832,0.1798,257.0276,348.0993,350.6876,1.2414,-1.2408,-0.4516

Even if I init the IMU and wait 10 seconds I still get a good reading:

1:OK857198,-2.6292,0.0000,0.0000,359.1136,0.0000,-0.0000,1.4589,-1.4561,-0.6125

However if I wait another 10 seconds I get an invalid reading with NaN's:

866219,-2.5751,nan,nan,nan,nan,nan,0.5479,-0.5540,0.0426

I now think that what's happening in the original bug report is that some network error causes the coin to either not send a response to the D command or the dongle to miss the response from the coin. Then if you wait too long before restarting the SET_REPEAT command the coin's IMU will time out and start yielding NaNs.

The time sensitive code in the FreeIMU code seems to be these lines in function FreeIMU::getQ(float * q, float * val) in FreeIMU.cpp:

now = micros();
sampleFreq = 1.0 / ((now - lastUpdate) / 1000000.0);
lastUpdate = now;

Ok, that sounds like it makes sense. Perhaps I can keep calling a FreeIMU function (if enabled) by adding FemtoCore::handleIMU(), which can then be called in the sketch loop() method.

[garnould]

Last commit in master (merged yesterday) seems to fix this bug (SET_REPEAT). Can you test and send feedback ?

[garnould]

Hi there,

I tried to fix NaN bug while traveling by train with no HW to test fix.

Commit is here => https://github.com/garnould/ArduinoCore-atsamd21e18a/tree/paneer_nan (branch contains only 1 commit ahead of master).

Didn't pull request because not tested yet. It compiles properly and should do the job.

Mainly : rewrote FemtoCore::sendSampleLegacy()

Until someone has tested until next monday, I'll send feed back then when I'll have hands on HW.

G.

[garnould]

Saw NaN's is some (not yet repeated) conditions : bug is not yet completely fixed.

[drogge]

Garnould, have you read my comment dated Oct. 1st? I'm almost positive that the NaN's are coming from the FreeIMU library. It seems to have something to do with doing a bunch of reads from the IMU, then waiting for something like 10 seconds and then reading again. I think the original bug report is the result of the running the SET_REPEAT command, the Beacon missing response from the coin and then restarting the SET_REPEAT without reinitializing the coin's IMU. This fits the "read a bunch, wait awhile and then read some more" pattern mentioned above. In converting the IMU hardware reading to something reasonable there seems to be some kind of a timing issue.I think it has to do with reading the gyroscope. I've been working with the FreeIMU lib separate from FemtoCore and to be honest I haven't had much luck; inconsistent behavior with running the same code twice, etc. It's all pretty much magic to me right now.

[garnould]

Hi drogge,

Thank you for pointing this to me.

I managed to reproduce the bug with coin:

• plug the coin and connect it with serial
• enter '1' for IMU init
• enter 'd' command
• wait for about 10 seconds
• enter 'd' again
• NaN's ...

I'll have a look at it.

[garnould]

Located the beginning of the bug:

• FreeIMU::getYawPitchRoll uses FreeIMU::getYawPitchRollRad
• FreeIMU::getYawPitchRollRad users FreeIMU::getQ (to feed 'q' and 'val'), then does some math on 'q' and 'val' to return ypr.

'q' being NaN's after getQ, NaN's received at the end.

In getQ, it looks like q (param) should be receive values from q0, q1, q2 and q3 (from FreeIMU class).

Except at init time, q0..q3 can be fed with values from:

• either a code portion from getQ that can't be reached because of defines,
• either a call to getQ_simple that is currently commented out.

Meaning at the moment, q0..q3 are receiving values only at init time.

When removing comment syntax on getQ_simple call, no more NaN's but the returned values of YPR are quite strange.

@alex: any magnetometer in FemtoBeacon ?

[zrecore]

@garnould yes, it has a built in magnetometer. The IC is the MPU-9250