Tuning the frequencies

[gauteh]

We are using the IMU in FIFO mode. The ODR sets the general output rate if you sample the IMU manually (i.e. read the value at the sample rate). In FIFO mode, an internal buffer is filled up on the IMU. The RTC (real time clock) interrupt in sfy-artemis/src/main.rs runs the routine at a specified interval configured in the setup code in main.rs. It calls code in lib.rs and then in waves.rs that drains the FIFO. If the buffer on the artemis is full, it makes a package and queues it for transmission home and resets the artemis-buffer.

The FIFO rate is configured with the BDR (probably in addition to the ODR), but both of those should be set correctly if you change the frequency constant. But if any of those are missing from the driver you need to make sure they are available both places.

[stianvikanes]

417Hz is okay. I am still working on how to increase it further. Your comment above is helpful (I locate the problem), but I still have not figured out how to make it work.

[stianvikanes]

I thought that if I enabled compression in FIFO (increase buffer size) i'd be able to do 833Hz, but it seems like it didn't do any difference. I'll leave it here, as it might have something to it, and i am not sure if I did it correctly :)

[gauteh]

I thought that if I enabled compression in FIFO (increase buffer size) i'd be able to do 833Hz, but it seems like it didn't do any difference. I'll leave it here, as it might have something to it, and i am not sure if I did it correctly :)

Nice :) I did not enable it since we don't react to FIFO-full events, but drain it at regular intervals. So we would risk that it works sometimes (in the lab), but not on real data with higher entropy.

It should be easier to get high sample-rate to work without storage enabled, worth trying that first!

Are you getting any errors? Or how do you recognize that it is failing?

[gauteh]

Maybe you need to decrease the loop-delay in the main loop. But if it turns out that the RTC interrupt is too infrequent, you may have to do FIFO draining (current RTC interrupt handler) in the main loop.

[jerabaul29]

Just curious: what frequency are you running the I2C port at? If I remember correctly the default frequencies of 100 or 400kHz are too low to sustain data transfer at 833Hz. But both the Artemis and the ISM support 1MHz I2C frequency (which is what I use om the OMB). Can this come into play, or are you already using 1MHz I2C frequency?

[gauteh]

Just curious: what frequency are you running the I2C port at? If I remember correctly the default frequencies of 100 or 400kHz are too low to sustain data transfer at 833Hz. But both the Artemis and the ISM support 1MHz I2C frequency (which is what I use om the OMB). Can this come into play, or are you already using 1MHz I2C frequency?

Yep, I'm pretty sure it is at 1 MHz now for the IMU. I think the modem can't do more than 100 kHz or 400 kHz, the SD-card can do many MHz (12 after initialization?). I think I was wrong, the port you have configured here in this PR is for the notecard, but it should still probably not be modified.

[stianvikanes]

I thought that if I enabled compression in FIFO (increase buffer size) i'd be able to do 833Hz, but it seems like it didn't do any difference. I'll leave it here, as it might have something to it, and i am not sure if I did it correctly :)

Nice :) I did not enable it since we don't react to FIFO-full events, but drain it at regular intervals. So we would risk that it works sometimes (in the lab), but not on real data with higher entropy.

It should be easier to get high sample-rate to work without storage enabled, worth trying that first!

Are you getting any errors? Or how do you recognize that it is failing?

Okay, good to know!

I am currently not having storage enabled. The error that keeps appearing is the TooFewSamples:

• ERROR Too few samples, IMU may be stuck: 3010
• IMU ISR failed: TooFewSamples(3010), resetting IMU..

It is originating from the check_retrieve function in lib.rs, because fifo_full = true

[stianvikanes]

Just curious: what frequency are you running the I2C port at? If I remember correctly the default frequencies of 100 or 400kHz are too low to sustain data transfer at 833Hz. But both the Artemis and the ISM support 1MHz I2C frequency (which is what I use om the OMB). Can this come into play, or are you already using 1MHz I2C frequency?

Yep, I'm pretty sure it is at 1 MHz now for the IMU. I think the modem can't do more than 100 kHz or 400 kHz, the SD-card can do many MHz (12 after initialization?). I think I was wrong, the port you have configured here in this PR is for the notecard, but it should still probably not be modified.

Correct, it is at 1mHz for the imu. The notecard was originally at 100kHz, so I just switched it back from 400, after trying.

[gauteh]

That explains it 😁

[stianvikanes]

Maybe you need to decrease the loop-delay in the main loop. But if it turns out that the RTC interrupt is too infrequent, you may have to do FIFO draining (current RTC interrupt handler) in the main loop.

I think I've figured out that the problem is the interrupt handler. It can interrupt at a frequency of CentiSecond but not faster, and that is not sufficient for sampling rate faster than 417Hz.

[gauteh]

Ok, then we can try to drain the FIFO in the main loop? That is a big change though.

tir. 18. jul. 2023, 11:32 skrev stianvikanes @.***>:

Maybe you need to decrease the loop-delay in the main loop. But if it turns out that the RTC interrupt is too infrequent, you may have to do FIFO draining (current RTC interrupt handler) in the main loop.

I think I've figured out that the problem is the interrupt handler. It can interrupt at a frequency of CentiSecond but not faster, and that is not sufficient for sampling rate faster than 417Hz.

— Reply to this email directly, view it on GitHub https://github.com/gauteh/sfy/pull/142#issuecomment-1639876065, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAN36Z4GLIMGAN2PX7LMNLXQZJ4RANCNFSM6AAAAAAZWYWMYQ . You are receiving this because you commented.Message ID: @.***>

[stianvikanes]

Ok, then we can try to drain the FIFO in the main loop? That is a big change though. tir. 18. jul. 2023, 11:32 skrev stianvikanes @.>: … Maybe you need to decrease the loop-delay in the main loop. But if it turns out that the RTC interrupt is too infrequent, you may have to do FIFO draining (current RTC interrupt handler) in the main loop. I think I've figured out that the problem is the interrupt handler. It can interrupt at a frequency of CentiSecond but not faster, and that is not sufficient for sampling rate faster than 417Hz. — Reply to this email directly, view it on GitHub <#142 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAN36Z4GLIMGAN2PX7LMNLXQZJ4RANCNFSM6AAAAAAZWYWMYQ . You are receiving this because you commented.Message ID: @.>

Yes, Let us try! Do you have any thoughts on how it would be done?

[gauteh]

The SHORT_LOOP_DELAY is to avoid doing too many checks, or communicating too much with the notecard since that uses more power.

You essentially have to call the contents of the RTC function in the main loop, and remove the asm::wfi and delay instructions. You can add a delay later. Alternatively we should set up another hardware connection from the IMU to the artemis and configure it to send a signal when the FIFO is 3/4 full, it would be the best solution, but I think this is too complicated to do now. You can investigate if you want. However, if you can make it work from the main loop that is anyway proof that we can later get it to work with some hardware modifications.

So you have to move most of the contents of the RTC function to the main loop, probably before the existing if-block. You could in theory simplify stuff with the queuing since it is now not on a different interrupt (which you can think of as a separate thread), but lets keep it so that we can later use the IMU interrupt.

[stianvikanes]

The SHORT_LOOP_DELAY is to avoid doing too many checks, or communicating too much with the notecard since that uses more power.

You essentially have to call the contents of the RTC function in the main loop, and remove the asm::wfi and delay instructions. You can add a delay later. Alternatively we should set up another hardware connection from the IMU to the artemis and configure it to send a signal when the FIFO is 3/4 full, it would be the best solution, but I think this is too complicated to do now. You can investigate if you want. However, if you can make it work from the main loop that is anyway proof that we can later get it to work with some hardware modifications.

So you have to move most of the contents of the RTC function to the main loop, probably before the existing if-block. You could in theory simplify stuff with the queuing since it is now not on a different interrupt (which you can think of as a separate thread), but lets keep it so that we can later use the IMU interrupt.

Thanks! I will look into it and see if I can make it work.