Be able to log PPS (Pulse Per Second) output with an interrupt to reach us timing accuracy

[jerabaul29]

I would be interested in using the OLA to be able to log time signals with really high accuracy (typically microseconds, us).

I have done this in the past, and this is actually not very hard: all what is needed is log the PPS (Pulse Per Second) pin of a GPS receiver with an interrupt, i.e. for example (may be possible to do even better):

• connect the PPS output of a GPS module to a pin PIN_IN
• enable a rising edge interrupt on PIN_IN
• set up the ISR to i) get the value of the us timestamp on the board and write it to a volatile variable, ii) set a flag that a rising edge time has been captured
• have a function, called regularly in the main program loop, that i) checks for the flag, ii) if set, logs the us timestamp and resets the flag. This function should be called typically twice a second, to make sure a rising edge is never lost (these will happen only every 1 s anyways)

Then, at post processing, I can interpolate the MCU time base from millis or micros onto the UTC time base by combining the logs from the GPS and from the PPS, and the interpolation / matching has us accuracy.

My question: could such a functionality be offered on the OLA (of course it may require soldering 1 wire PPS <-> interrupt enabled pin, but that is fine enough :) )? That would be super useful and make the OLA usable for many more applications on my end :) .

[PaulZC]

Hi JR,

Could you please describe what your ultimate goal is a little more? Is it to ensure you have (very) accurate timestamp information for the measurements made by the other sensors connected to the OLA? I.e. the absolute time of this reading on this sensor was this many microseconds?

The sensor I2C transfers take a finite amount of time. Sometimes there is a delay between requesting a reading and the sensor returning the data. If you have multiple sensors connected then the absolute time of each reading will be staggered. The data logged to file includes the Real Time Clock value (with micros if desired) at the time of the start of the getData function.

The OLA already has a trigger mode, so you could use the GPS PPS to trigger each reading and know that they are exactly 1s apart. But again this does not tell you the absolute time of the sensor readings collected each second...

Best wishes,
Paul

[jerabaul29]

Sorry for the long discussion, this ends up being half way general brainstorming / half way discussion and specification of my actual case :) .

I make the hypothesis that the OLA can be kept awake all the time for the measurements I am interested in (for high resolution measurements, for example GPS at full rate + ISM330DHCX at full rate + possibly other sensors, having the Artemis always on should not be a noticeable electrical power cost anyways - 0.5mA for the Artemis vs. 35mA for the GPS?).

I agree that if basing timing on the I2C receive time for getting the timestamp of the measurements, there may be a lot more uncertainty than us - maybe rather of the order ms or a few ms? Note that this is still likely a lot better than what could be obtained from "just" comparing to logged GPS string, as these GPS strings have a +- 0.5 s uncertainty typically (I do not think we can have ms accuracy by looking at "time of arrival" of the GPS NMEA messages).

In my present application, ms accuracy would be enough, so I guess this quick and dirty "timing from time of receiving on the I2C bus" would be enough?

In my previous application, I was measuring some analog signal with the ADC of my board, running the ADC of my board in "free running mode" and having the ADC generate an interrupt each time an ADC conversion was ready for logging it. This allowed generating a microsecond accurate timestamp of when the ADC conversion was done, and the PPS was also interrupt logged with microsecond accuracy, so I think I really had microsecond timing accuracy on this signal (we were able to triangulate the source in space and time of elastic waves in sea ice going at typically km/s speeds, from loggers a few 10s to 100s of meters apart; if you are interested, see: https://github.com/jvoermans/Geophone_Logger ; this was using an Arduino Due though).

IMO including a PPS interrupt driven us accuracy timestamp on the OLA would be a first step to get really accurate time referencing by allowing to map OLA us timer to UTC time with a typically us accuracy. With this in place, the OLA that could be picking up other interrupts, picking up signals from the ADC, picking up I2C signals (though as you say this may be ms rather than us accurate in order of magnitude), etc, and reference these accurately regarding to UTC (us if timing is determined by a separate interrupt pin, probably ms-ish if using "time of data retrieval" on data buses).

A note on I2C signals: I think that many sensors (for example, the ISM330DHCX) can be programmed to provide a high logical signal on an "interrupt output pin", so even if the I2C data retrieval time is not enough to get us accuracy per se, logging the I2C signal + the time of the ISM330DHCX interrupt output indicating that the measurement is ready may allow to go down to us accuracy.

In the application I have in mind, ms would actually be enough anyways, so I guess logging the PPS through interrupt at us resolution, and the measurement time of arrival through I2C at us resolution, but keeping in time that the I2C thing may introduce delays etc so this may only be ms accurate, may be enough.

Sorry for the long explanation, let me know if anything is unclear / not coherent etc. What I mean in the end is that it would be nice if the OLA could retrieve the PPS GPS output and interrupt log it with us accuracy, and similarly, consider logging other sources of data (ADC reading with interrupt, other input pin with interrupt, I2C either with time of data retrieval or separate interrupt pin indicating the end of conversion), also to us accuracy, even if in some case only ms accuracy may be trusted. For several applications I am involved in, this would make the OLA very attractive (for example, replacing the Arduino Due by an OLA in the application above would be very nice, though the current thing I have in mind is something else).

We can have a chat over Zoom or GMeet some day if you want :) .

[jerabaul29]

The preprint corresponding to the code mentioned above is now released, see:

https://arxiv.org/pdf/2305.06490.pdf

Basically, by using the PPS signal (logged through an interrupt routine to match it to the internal clock / millis() counter, which we use for timing ADC measurement / logging of additional sensors) for synchronization across several loggers, we are able to triangulate the source of mechanical waves propagating at around 2km/s to determine the location of glacier calving: https://arxiv.org/pdf/2305.06490.pdf . This is the kind of things that would be great to be able to do "out of the box" with some PPS-enabled OLA (both for us and also likely for other applications, by having a "typically us PPS absolute time accuracy", lots of applications involving triangulation of signals become doable).

[PaulZC]

Hi JR,

Thanks for the update. Nice paper!

To be honest, I'm still not convinced the existing OLA + firmware is the correct choice for projects like these. With the Due hardware + firmware you have much better control over the A2D sampling and PPS interrupt capture. I think adding the GPS interrupt time capture on the OLA is probably achievable, and it may be possible to better record the time of each individual A2D sample, but it is a lot of work and very different to how most users use the OLA.

I think you would do much better to produce a "shield" PCB for the Due, with the amplifiers, SD card and GPS module all designed onto one PCB?

Best,
Paul

[jerabaul29]

Thanks :) . Credits should go to @jvoermans really :) .

The method of a "home made, hand soldered shield for the Due" is already what we do (see the details at https://github.com/jvoermans/Geophone_Logger/tree/main/Hardware ). The reason why we would be interested to change to the OLA are:

• i) much better power consumption (the Due is crazy power hungry; I do not remember the value, @jvoermans could provide the details, but I think we were at ~100mA or something like this? Going down to a couple of mA with the Ambiq would make a huge difference for battery requirements in the polar temperatures :) )
• ii) much easier assembly (SD already included, qwiic to GPS, easy to add ISM330DHCX also if we want)

I agree on the Due I had to do quite a bit of coding to get the ADC high frequency logging to work well, see: https://github.com/jvoermans/Geophone_Logger/blob/main/Firmware/src/FastLogger.cpp . However if using the Ambiq, I think that the frequency of the MCU is so high in boost mode and there is so much RAM that most of this low level stuff could be simplified. But agree that this may still "require" adding a "ADC high frequency logging" module to the OLA, which may be quite a bit of work (though may be really useful for a range of projects if this can be made easy to set up through the config editor).

Independently if this gets implemented or not in the present case, I guess this is good to keep in mind - these are useful functionalities in general, would be great to get either in this or future projects and firmwares :) .

[jvoermans]

By coincidence I see that @jerabaul29 already put out a request for this :)

Accuracy of time stamps at order of milliseconds has quite a few advantages. Old environmental monitoring systems (temperature, wind speed, accelerometer etc.) cannot always have their individual sensors replaced as they simply have no replacement components available anymore. Rather than buying a whole new system that can cost a fortune, having the openlog as parallel system to replace such a sensor is extremely valuable. The millisecond-accuracy timestamps of GPS can then be used to time match with the other system.

[cuzzard]

Agreed that this would be a useful feature for some more demanding applications.

I have tried to use the OLA to log RTK GNSS data on a drone carrying a third party sensor acquiring data at a sample rate of 1kHz whilst travelling at speeds up to 10 m/s.

A ms time accuracy is needed to match sensor data to an accurate position in processing; without it the end result is not as good as it could be.

P.S. @jvoermans, the hookup diagram (https://github.com/jvoermans/Geophone_Logger/tree/main/Hardware/Fritzing_diagram.png) shows no PPS pins connected. Is this right?

[jvoermans]

@cuzzard Well spotted. PPS pin should be connected to pin 2, but seem to have forgotten in the Fritzing diagram, I'll try update it this week. Thanks for noticing. https://github.com/jvoermans/Geophone_Logger/blob/053add64e620f63fdd7cbf892e0924d38cf7f591/Firmware/src/params.h#L79