Topics

1

General Discussion / NRFL01+ 2.4 GHz Radio Shield / Documentation missing

« on: January 09, 2021, 04:58:06 AM »

I am busy with a project with GPS, MicroSD (for logging) and radio (downlink of selected data).

I have started with the NRF24L01+ 2.4 GHz shields for the radio link because of availability.
I am now facing some compatibility problems between radio and microSD, both acting with SPI. I hope it is SW only.

But looking for documentation I found that the schematic links in both shop and learn parts lead to the schematic of the 433 MHz Radio Shield instead of the 2.4 GHz Shield.

I am sure that  both schematics show differences with respect to the RF parts  but also with e.g. the SPI chip select, because the related RadioHead settings for chip select and interrupt pins are different.

The compatibility matrix does not provide indications of incompatibilities between MicroSD and NRFL01+ 2.4 GHz Radio Shields, but the related excel table is clearly another version with at least MicroSD & Audio and 2.4 GHz Radio Shields missing.

Can you provide me with the schematic of the NRFL01+ 2.4 GHz Radio Shield?


Regards,
Willem

2

General Discussion / ZOE GPS proto board in 35 mm model rocket application / Results

« on: December 30, 2020, 05:33:05 AM »

This last post on the ZOE GPS proto board in a small 35 mm rocket application deals with the main results of launch trials of the MER-35-ZOE model rocket.

Two launches of this rocket were executed on 9 November 2020 at Laren (Gld.), The Netherlands.
Weather was excellent for launching.

For an overview and detailed figures see the attached presentation.

Given the used Klima C6-5 rocket motor with a specified peak thrust of 15 N and a total rocket mass of 130 + 21.5 ~ 152 g it is clear that the acceleration limit of 4G in the dynamic platform model of the ZOE-M8B will be exceeded at least for a short time interval during the boost phase.
It depends on the model estimates inside the ZOE if this will be detected resulting in missing position fixes or not.
 
Main results

Herewith some main values for launch #1 resp. launch #2, see also slide 9 of the attachment:

-   Maximum forward acceleration (corrected for gravitation): 10.2 G, 10.0 G
-   Average forward acceleration during boost phase: 4.4 G, 3.9 G
-   Maximum altitude (above ground level / barometric): 135 m, 134 m
-   Maximum altitude (above ground level / GNSS): 134 m, 134 m
-   Trajectory length (by double integration of forward acceleration): 146 m, 135 m
-   Trajectory length (GNSS, step by step): 146 m, 137 m

The maximum forward accelerations are somewhat higher than expected (~9 G).

Average forward acceleration at launch #1 was higher than that of #2 resulting in max vertical velocities of 54 m/s and 49 m/s respectively. However, max altitudes were nearly the same (135 and 134 m). Launch #2 was more vertically oriented leading to a much smaller difference between trajectory length and altitude as was also visible on site and on videos.

Model rocket trajectories

The different trajectories can be visualized by the following figure, in which GNSS longitude (x), latitude (y) and altitude (z) are depicted relative to launch point:
 

(Figure 1, see attachment, sheet 11)

Launch #2 is much more vertically oriented as can also be seen from rotated versions of this figure (see attachment). In the trajectory of launch #1 six position fixes are missing, presumably because of too high forward acceleration, “too much > 4G”.

Altitude and other measurements

Altitudes (corrected for ground level at launch) measured by both barometers and GNSS are rather close to each other as can be seen in the next figure for launch #1. Correction for time alignment was not necessary.


(Figure 2, see attachment, sheet 15)

The barometric altitudes have a more noisy character. It would help a bit to take the average of the outputs of the two barometers or to use more averaging per barometer.

The GNSS altitude curve is rather smooth, but it is striking that the altitude after touchdown is more negative than the height of the launch platform. So the GNSS altitude also includes some random walk effect.

The two barometric outliers relate to measured pressure peaks (so altitude dips) during ejection of the nose cone section including parachute.

For figures showing forward acceleration and roll rotation please refer to the attachment.

Because of the canted fins which are designed for a roll rate of 2000 deg/s (~5.6 Hz) at a forward velocity of 40 m/s, it is expected to see the roll rate increase with increasing forward velocity. This is indeed the case.
Also note that the LSM9DS1 gyro output saturates just above 2000 deg/s conform specification.
This happens in fact at ~6.4 Hz.
Magnetic field attitude readings are used to fill in the saturated gyro part.

Conclusions

It has been shown that the ZOE GPS prototype board can be successfully applied in a small 35 mm diameter model rocket.

ZOE setup modification through UART only took some effort, but proved to be done in a reliable way.

The trials were successful with 5Hz GNSS and ~50 Hz sensor data.

The ZOE-M8B gave six missing position fix data during the boost phase of launch #1, the one with the higher forward acceleration.

As next step it is planned to implement “Enable position output for invalid fixes” using the UBX-CFG-NMEA command in the ZOE setup in order to avoid missing position fix data in follow-up trials.


Regards,

Willem

3

General Discussion / ZOE GPS proto board / ZOE setup with examples

« on: December 03, 2020, 07:29:24 AM »

In this post it is described how to change the configuration of an u-blox M8 GNSS receiver using UART communication. Focus is on the u-blox ZOE-M8B. Most examples are configuration changes necessary for model rocket applications.

Ben Rose  gave me the opportunity to test and evaluate a ZOE GPS prototype board, see the posts “GPS TinyShield does not provide actual altitude” and “ZOE GPS proto board in 35 mm model rocket application / Introduction” on the forum.

The ZOE GPS prototype board that I received is a bit bigger board, about TinyScreen+ size, with u-blox ZOE-M8B GNSS, Bosch BME280 (combined humidity and pressure sensor), ST LSM9DS1 (3D accelerometer, 3D gyroscope and 3D magnetometer) and microSD slot.

I connected the ZOE proto board with a TinyZero using the TinyShield expansion bus. Because of components on both ZOE proto board and TinyZero it is necessary to put another board in between. In my 35 mm model rocket application I finally used a Barometric pressure TinyShield between ZOE proto and TinyZero, but another board like the standard TinyShield proto board with both top and bottom bus expansion also works fine.

By default u-blox M8 GNSS receivers give 6 NMEA (GGA, GLL, GSA, GSV, RMC and VTG) messages at 1 Hz at 9600 baud rate and take into account  a “portable” platform model e.g. assuming low acceleration and a maximum vertical velocity of 50 m/s.

The ZOE-M8B has a bit different firmware (SPG 3.51) than most other u-blox M8 receivers optimizing a very low power consumption. It has “Aggressive with 1 Hz” as default power mode setup (PMS) related to its  “Super-E mode”.  With static tests I found that the ZOE, which I had given a 5Hz update rate, changed this automatically to 1 Hz after about 5 minutes presumably to reduce power consumption.

I also found that SBAS (Satellite-based augmentation system) is not enabled by default in the ZOE in contrast with e.g. the SAM-M8Q GNSS receiver, so if this is not changed, the ZOE will never provide a Differential GPS fix taking into account some provided corrections. In the ZOE-M8B datasheet, see [1],  it is stated “Tracking SBAS satellites uses power and requires a long decoding time. It is recommended to disable SBAS for Super-E mode.”

For many applications it will be necessary to modify the configuration of the ZOE-M8B (or another M8 GNSS receiver). In this post I will elaborate how to change the ZOE configuration in the setup part of the TinyZero code and how to gather the related evidence.

The I2C pins of the u-blox ZOE-M8B GNSS on the ZOE GPS prototype board  are not connected, so it is not possible to use I2C for control. The backup voltage pin is not connected either, so all commands (following the UBX protocol) to modify the default ZOE setup have to be given through the UART1 which is connected to IO0, IO1 and ground, so available at the TinyZero under the HW UART “Serial”.


Overview

For my 35 mm model rocket application I made the following changes:

-   Disable all NMEA messages (6 x UBX-CFG-MSG) in order to ease catching the ZOE responses (acknowledge, results of polling) after other UBX commands
-   Change the dynamic platform model (UBX-CFG-NAV5) to 8 (Airborne <4g)
-   Change power mode setup (PMS) to "balanced" (UBX-MSG-PMS)
-   Change the NMEA message rate to 5 Hz (200 ms) (UBX-MSG-RATE)
-   Change the baud rate to 57600 (UBX-MSG-PRT)
-   Enable NMEA messages GGA, GSA and VTG again (UART1 only) (3x UBX-CFG-MSG)

Additionally, I will also show how to enable SBAS by UBX-CFG-GNSS, because after this command the ZOE will reset and provide both acknowledge (in UBX format) and TXT strings (in NMEA format).

When enabling SBAS it is also important to check and perhaps change the SBAS satellite PRN masks to enable the right satellites depending on the area you are in. For Europe the right ones are already in the default configuration but it is advised to make the selection as small as possible. I have experimented myself with enabling EGNOS satellites PRN 123 and PRN136 only by UBX-CFG-SBAS.

In order to see if SBAS satellites are received by the ZOE I have included NMEA GSV messages and left the data rate at 1 Hz in the example code.


Connect with u-blox u-center

The u-blox M8 receiver description including protocol specification, see [2], provides a good overview and  a solid description of the M8 GNSS receiver family, NMEA protocol messages and UBX protocol messages.

However, it is not that easy to compose the UBX messages based on the document only. This holds especially for the long and more complicated commands like UBX-CFG-NAV5 and UBX-MSG-GNSS, but also for the shorter commands it is simpler and safer to use examples that can be derived from outputs from the u-blox program u-center, GNSS evaluation software for Windows [3].

To interface with u-center I used a simple passthrough code on the TinyZero (“SerialPassthrough_a.ino”, see first attachment) which is directly derived from the code from the examples in the Arduino program (tab File, Examples,  04.Communication, SerialPassthrough). Main adaptation is that Serial1 has been replaced by SerialUSB. The attached code can be used by the Arduino program for verification and upload to the TinyZero.

In this way all UART communication from ZOE to TinyZero is translated to communication from TinyZero to PC and vice versa. The u-center program has to be connected to the actual COM port, which should be the same as used to upload the TinyZero.

In u-center you can see the NMEA strings passing by on the Text console, but also the detailed configuration in the Configuration View. The configuration can be changed in a very user friendly way and checked by polling. These changes will be lost after switching off the ZOE, because local saving is not possible in case of the ZOE GPS prototype board.

However, you can save the actual configuration in a .txt file (Tools, Receiver Configuration, Configuration file (provide name) and Save configuration (push button Transfer GNSS -> File)) for reference.

The default configuration file of the ZOE-M8B that I saved can be found in the 2nd attachment.

The configuration file includes many UBX command kernels. By comparing the configuration file  after a change in u-center with the default one you can detect the difference(s).

Nearly all configuration changes can be worked out this way and even tested. An exception is changing the baud rate, which works fine in a direct connection with an u-blox M8 receiver, but does not in an indirect one with passthrough. In u-center it is possible to change the power mode setup (PMS), but this is not one-to-one reflected in a kernel of the UBX-CFG-PMS message, because that one is not in the list.


Compose a UBX command / example to disable NMEA GGA strings

Let us first disable the NMEA GGA message in u-center. In u-center we go to tab View, Configuration View, MSG(Messages), look for message F0-00 NMEA GxGGA and disable all ports (I2C, UART1, etc).

Then we push the Send button and check if all ports remain enabled by pushing the Poll button. When we save the configuration to file under another name, we can find in this file a line with text:

CFG-MSG - 06 01 08 00 F0 00 00 00 00 00 00 00
 
While the same line in the default configuration shows as:

CFG-MSG - 06 01 08 00 F0 00 01 01 00 01 01 00

In these lines stands “06 01” for CFG-MSG, “08 00” for the length (8 bytes) of the “payload” part of the UBX message and “F0” for GxGGA. The meaning of all bytes is described in [2], par. 32.10.14.2.

We now have the kernel of the UBX message to disable the transmission of NMEA GGA over all ports:  06 01 08 00 F0 00 00 00 00 00 00 00 (all hexadecimal bytes 0x06 etc.)
We just need to add the UBX header with  “B5 62” in front of the kernel and to add the 2 byte standard UBX checksum, see [2], par. 32.2 and 32.4.

It is possible to calculate the checksum in the TinyZero code, but I have chosen to do it in a simple semi-manual excel file, see 3rd attachment for better understanding how it works.

The checksum is important. If the checksum is not correct, the ZOE does not react at all.

The total code for this message is (all (hexadecimal) bytes):
B5 62 06 01 08 00 F0 00 00 00 00 00 00 00 FF 23

In the setup code the char bufferMSG[16] is filled with this sequence and send to the ZOE with a “serial. write”, see for complete code, “GPS_Monitor_ZOE_a.ino”,  in the  4th attachment.

The composition of the other messages is done in the same way, so the code to enable NMEA GGA again for UART1 only is e.g.:
B5 62 06 01 08 00 F0 00 00 01 00 00 00 00 00 28

In some cases it also helps if the default configuration of another u-blox M8 GNSS receiver, e.g. SAM-M8Q is available for comparison.


Catching ZOE responses

After receiving a command the ZOE will react with an acknowledge message, also in UBX format. This can be an “ack-ack” or an “ack-nack”, depending on whether or not the message was processed correctly by the ZOE. See [2], par. 32.5.1.

The “ack-ack” of all CFG-MSG commands is the same:

B5 62 05 01 02 00 06 01 0F 38

So it is important to group commands in a logical way. The 4th byte 0x01 means that it is an “ack-ack”, 0x06 0x01 indicates CFG-MSG.

In the code (see attachment 4)  I have included a number of while loops to gather the response of the ZOE after a group of commands.

Most responses are in UBX format, so a series of bytes (hexadecimal), but in some cases there are still some NMEA strings coming (series of char), so it is important to try to distinguish between both formats. This is done in a oversimplified non-exhaustive way, just to ease the interpretation of the data. NMEA strings should start with $ (= 0x24), while UBX strings start with 0xB5. 0xB5 is not part of an NMEA string, but 0x24 can be part of an UBX message.

Furthermore, I have chosen to display UBX messages with commas between the bytes (and omitting leading zeros) to improve the readability and to simplify pasting e.g. in an excel file for comparison.

So “ack-ack” of CFG-MSG is transformed to:

B5,62,5,1,2,0,6,1,F,38

After the UBX-CFG-GNSS command to enable SBAS (with bufferGNSS[68]), the ZOE does not react only with an “ack-ack” but also resets GNSS and gives 3 NMEA TXT messages:

$GNTXT,01,01,02,Resetting GNSS*3B
B5,62,5,1,2,0,6,3E,4C,75
$GNTXT,01,01,02,ANTSTATUS=INIT*3B
$GNTXT,01,01,02,ANTSTATUS=OK*25

In some important cases I asked for confirmation of the execution of the command with more detail.
This is done by sending a polling message, e.g. to check if the dynamic platform model has been changed (in this case to , the polling message for CFG-NAV5, only 8 bytes, is sent:

B5 62  06 24  00 00 2A  84

The ZOE will react with the complete CFG-NAV5 and the related “ack-ack”(commas are added):

B5,62,6,24,24,0,FF,FF,8,3,0,0,0,0,10,27,0,0,5,0,FA,0,FA,0,64,0,5E,1,0,3C,0,0,0,0,0,0,0,0,0,0,0,0,86,4C
B5,62,5,1,2,0,6,24,32,5B


Example code for monitoring and logging ZOE output (setup and after)

As already mentioned, attachment 4 contains an example code “GPS_Monitor_ZOE_a.ino” for changing the ZOE code (in setup) and monitoring the results on PC or logging these on microSD or both at the same time.

The code includes many lines in void setup() and just a few in void loop ().

After first definitions and declarations Void setup() starts with lines to secure ZOE GPS SAFEBOOT_N and RESET_N pins in high state to avoid problems.

A string buffer (buffer1) is used to overcome waiting problems with writing the microSD card.

For the bulk logging process writing is only done in blocks of 512 bytes. The size of buffer1 is rather big, 2k Bytes, but the TinyZero can handle bigger data memories.

After opening the .txt logging file with an updated 3 digit number file name, the ZOE configuration is modified:

-   suppress all default NMEA strings (GGA, GLL, GSA, GSV, RMC and VTG) to be sure that acknowledge and polling messages are clearly received
-   Gather ZOE response (6x “ack-ack”), (with some NMEA strings in the pipeline)
-   Adaptation of CFG-GNSS to include SBAS (leading to reset GNSS)
-   Gather ZOE response (“ack-ack” and  3 $GNTXT strings),
-   Adaptation of dynamic platform model (->8 = Airborne <4g) using NAV5
-   Prepared for alternative PMS: Adaptation of power mode setup (PMS) to “full power”
-   Adaptation of power mode setup (PMS) to "balanced"
-   Gather ZOE response (2x “ack-ack”)
-   Polling NAV5 in order to check the correct adaptation of the dynamic platform model
-   Polling PMS in order to check the adaptation of the power mode setup
-   Polling GNSS in order to check the adaptation of the configuration to include SBAS
-   Prepared for: RATE -> 5 Hz (200ms) / Note: Prepared for, because of additional enabling of NMEA GSV will can result in many NMEA strings
-   Gather ZOE response (results of polling NAV5, PMS and GNSS plus 3x “ack-ack”)
-   Modification of baudrate to E1 (225) x 256 = 57600 using PRT
-   Enable NMEA strings GGA, GSA, GSV and VTG on UART1 only
-   Gather ZOE response (4x “ack-ack”), followed by first NMEA strings


Void loop() writes incoming char in buffer1. Buffer1 has overload protection. In case of overload some incoming char will not be written. Such an event will be visible in the output by some blank lines.

When the contents of buffer1 has reached 512 bytes it is checked if the microSD is available for write, and if so, a block is written.

A 5th attachment containing the first part of a logging on microSD will follow as example of an output file.


Final remark

If there are questions or errors found, please let me know.


[1] ZOE-M8B datasheet (ZOE-M8B_DataSheet_(UBX-17035164).pdf): https://www.u-blox.com/en/docs/UBX-17035164
[2] u-blox8-M8_ReceiverDescrProtSpec_(UBX-13003221).pdf): https://www.u-blox.com/en/docs/UBX-13003221
[3] u-blox program u-center: https://www.u-blox.com/en/product/u-center


Regards
Willem

4

General Discussion / ZOE GPS proto board in 35 mm model rocket application / Introduction

« on: November 20, 2020, 04:43:46 AM »

Ben Rose  gave me the opportunity to test and evaluate a ZOE GPS prototype board, see the post “GPS TinyShield does not provide actual altitude”  on the forum.

In the current post I will describe how I used this ZOE GPS proto board in a small model rocket application where I wanted to record GNSS position (latitude, longitude and altitude) of the model rocket at 5Hz as well as barometric altitude, accelerations, gyroscope and magnetic field readings at about 50 Hz.

Functionality and HW aspects

The ZOE GPS prototype board that I received is a bit bigger board, about TinyScreen+ size, with u-blox ZOE-M8B GNSS, Bosch BME280 (combined humidity and pressure sensor), ST LSM9DS1 (3D accelerometer, 3D gyroscope and 3D magnetometer) and microSD slot. These chips and related support components are placed on one side of the board.

The ZOE-M8B is a very small GNSS chip, member of the u-blox M8 product family and working at only 1.8 V with a very lower power consumption also thanks to the default “Super-E mode”. Data connection of the ZOE on this proto board is through UART only. The I2C pins are not connected. The backup voltage pin is not connected either, so all commands to modify the default ZOE setup have to be given through the UART which is connected to IO0, IO1 and ground, so available at the TinyZero under the HW UART “Serial”.

ZOE pins SAFEBOOT_N and RESET_N are connected to AD2 and AD3. It is essential to apply statements to set AD2 and AD3 high early in setup to ensure that these ZOE inputs are safe.

The ZOE proto board has been connected to a TinyZero using the TinyShield expansion bus. Because of components on both ZOE proto board and TinyZero it is necessary to put another board in between. At first I used a standard TinyShield proto board with both top and bottom bus expansion between ZOE proto and TinyZero.

The BME280 on the ZOE proto behaves exactly the same as the BMP280 for the temperature and pressure settings I am using. The BME280 is also downward register compatible to the BMP280 (with some exceptions not applicable for my case), so the code of BMP280.h and .cpp can be reused.
However, the BME280 as mounted on the ZOE protoboard has a different I2C address, 0x76 instead of 0x77, so  this has to be changed in BMP280.h.

This also means that it is possible to log two barometric altimeters, so I replaced the standard proto board TinyShield between ZOE board and TinyZero by a Barometric pressure TinyShield.

Some static tests have been executed with a 9x9 mm passive GPS patch antenna originally belonging to the GPS TinyShield. The sensitivity was clearly less than that of the much bigger Sparkfun SAM-M8Q breakout board, but sufficient for the model rocket application. Main advantage of this small antenna is that it is very light and every gram counts in model rocketry.

The 3 boards and the 9x9 mm GPS antenna have been mounted on and in a kind of harness, designed and 3D printed in PETG at home, see pictures. The boards are placed in the length on a thin plate of the harness, with a 150 mAh battery glued with double sided tape at the other side. The harness with boards, antenna and battery weights 18.5 gram.

The harness can be  placed in a 3D printed PETG container and locked with a ring and a PETG screw cap. This container with nose acts as an extended nose cone, see picture. The total weight of the model rocket without motor is ~130 gram, only 4 gram more than the previous version with sensor logging, but without GNSS. With a Klima C6 motor an altitude of 130 - 140 m can be expected.

ZOE setup

For my envisaged application in a small 35 mm diameter model rocket, setup changes are necessary, because by default 6 NMEA messages are given at 1 Hz  (9600 baud rate) taking into account a “portable” platform model e.g. assuming low acceleration and a maximum vertical velocity of 50 m/s.
So I changed the setup to only 3 NMEA messages (GGA, GSA (for GPS and GLONASS separately), VTG) at 5 Hz (57600 baud rate) and the most dynamic platform model available called “Airborne <4g”.

With static tests I found that the ZOE changed its 5Hz rate automatically to 1 Hz after some time presumably to reduce power consumption. In contrast with e.g. the u-blox SAM-M8Q GNSS, the ZOE-M8B has “Aggressive with 1 Hz” related to its  “Super-E mode” as default power mode setup (PMS).
This has to be changed to "Full power" or "Balanced" to be sure that 5Hz is maintained. This means a higher power consumption, but that is not an issue for model rocket trajectories with a short duration.

In a separate post I will elaborate the ZOE-M8B setup modifications through UART.

SW aspects

Based on earlier logging SW programs a SW version was prepared and tested (at fixed position) to log in a .txt file:

- U-blox M8 GPS setup data, e.g. platform model 8 (Airborne <4g), power mode setup 1 (Balanced), 5 Hz, baudrate 57600, NMEA strings: GGA, GSA (GPS and GLONASS), VTG.
- GPS strings every 200 ms

and in a .csv file:

- administration: time stamps, NMEA string received or not, internal buffer data, etc.
- acceleration (3 axes simultaneously) and temperature of BMA250 on TinyZero,
- altitude and temperature of BMP280 on Barometric pressure shield
- altitude and temperature of BME280 on ZOE board
- magnetic field (3 axes simultaneously) of LSM9DS1 on ZOE board
- gyro (3 axes simultaneously) of LSM9DS1 on ZOE board
- acceleration (3 axes simultaneously) of LSM9DS1 on ZOE board

Measurement cycle of all .csv data: ~ 19 ms, so > 50 Hz,  with a very limited number of longer cycles (less than 20 cycles  > 42 ms in ~ 100,000 cycles in stationary test run). These longer cycles are related to microSD access issues despite the use of block writing (blocks of 512 bytes).

Launch trials

Two launches of this rocket called "MER-35-ZOE" were executed on November 9. Weather was excellent for launching. See picture of launch #1 from below / side.

The acceleration limit of 4G in the dynamic platform model is exceeded for a short time interval during the boost phase. It depends on the estimates inside the ZOE if this will be detected or not.
 
Acceleration at launch #1 was higher than that of #2 resulting in max vertical velocities of 54 m/s and 49 m/s respectively. However, max altitudes were nearly the same (135 and 134 m). Launch #2 was more vertically oriented.

Parachute ejection occurred nicely in time. No model rocket damage after landing. Boards and battery were still mechanically fixed on the harness.

NMEA GNSS strings and other sensor measurements have been well recorded during both flights.

During ascend phase of flight #1 six NMEA string groups are missing the position values and flagged with indication “No position fix (at power-up, after losing satellite lock)” or “GNSS fix, but user limits exceeded” in the GGA and GSA strings, which gives the same flag. This did not happen with flight #2, presumably because of the bit lower acceleration of this flight.

Further results will be detailed in a separate post, but no errors or very strange things were discovered up to now.

Conclusion

It has been shown that the ZOE GPS prototype board can be successfully applied in a 35 mm diameter model rocket.
ZOE setup modification took some effort, but can be done in a reliable way.

5

General Discussion / HW UART for GPS logging with TinyZero

« on: September 23, 2020, 10:42:35 AM »

I have implemented logging of GPS NMEA strings on microSD using SW UART in the communication between the GPS (u-blox SAM-M8Q GPS on the Sparkfun GPS 15210 board) and a TinyZero with additional shields, see also post “TinyShield does not provide actual altitude” on this forum. This works fine for the GGA, GSA and VTG strings at 5 Hz.

The SW UART is using the “SoftwareSerialZero” set of routines. This works, but the highest working baud rate  that can be reached in this application is 19200.

I would like to use a higher baud rate, e.g. 38400, because currently the communication from GPS to TinyZero takes much more time than the communication from TinyZero to microSD. The latter is done in very efficient blocks of 512 bytes.

It has been tested that the GPS can work on this higher baud rate of 38400 with the same NMEA strings using the u-blox programme u-center on PC with windows 10 using a USB to UART Bridge.

I have tried to implement the HW UART using IO0 as RX (at Processor-side), IO1 as TX and GND. RX connected to TX at GPS-side and TX to RX at GPS-side. Furthermore I have defined the serial as “Serial1”, because that would be logical for Arduino Zero derivatives. This does not give any errors during compilation, so "Serial1" is recognized, but it is not working even at a baud rate of 9600. No character is received.

What is wrong?

Are the “Serial1” related pins located elsewhere in case of TinyZero?

It would also be logical that additional definitions or routines are necessary, but up to now I could not find anything. What is missing?

Please help.

6

General Discussion / GPS TinyShield does not provide actual altitude

« on: July 20, 2020, 04:20:25 AM »

The Telit JF2 GPS on the GPS TinyShield showed not to be able to follow rapid changes in height.

Based on the example from the GPS TinyShield Tutorial I have made a data logger with a TinyZero Processor Board with accelerometer, a GPS TinyShield and a MicroSD TinyShield. This logger is primarily meant for model rocket applications.
Using two separate buffer memories GPS NMEA strings are recorded in a .txt file and accelerometer outputs, time stamps and other administrative data like buffer usage are recorded in a .csv file.

The NMEA GPS string set consists of GGA, GSA and VTG strings at 5 Hz and GSV strings (normally 3 strings) at 1 Hz.
The 5 Hz command for the Telit JF2 GPS  has been taken from the chapter ” Enable 5Hz Update NMEA” from “Telit_Jupiter_JF2_EVK_User_Manual_r0.pdf” found on internet:
"$PSRF103,00,6,00,0*23\r\n"

To enable sufficiently fast communication between Telit JF2 GPS and TinyZero the baud rate has been increased from 9600 to 19200 after first initialization of the Telit JF2. To set this baud rate at the Telit JF2 side I have used the NMEA command:
"$PSRF100,1,19200,8,1,0*38\r\n"

The functionality of this logger application has been tested under static and dynamic conditions, e.g. car trips. Overall, it works fine on standard, x-y trajectories.

A vertical oriented trajectory was tested using a medium sized low power model rocket, MER-75.
The data logger with the GPS was placed in a specially prepared payload bay in the nose cone of the model rocket. A 2nd data logger consisting of a TinyZero Processor Board, a Combo Sensor TinyShield and a MicroSD TinyShield was placed in another payload bay at the bottom of the model rocket between the model rocket motors. Accurate time synchronization of the logger recordings was done afterwards by matching the z-axis accelerations during the start ramp of the boost phase. This synchronization enables direct comparison of the altitude from the GPS TinyShield and the altitude from the barometric pressure sensor of the Combo Sensor TinyShield. Furthermore, a separate Altimeter 2 was included in the payload bay in the nose cone.

The trial was executed on July, 11 near Almere, The Netherlands, with a surface height of -6 m with respect to sea level. Readings of the Altimeter 2: Apogee: 94m, altitude at parachute ejection: 90 m above ground level.

The attached figure vertically shows the altitude (in m) derived  from the barometric pressure sensor and the GPS for the time interval including model rocket launch, boost phase, ballistic phase, parachute ejection etc up to soft landing. The horizontal axis shows the time in milliseconds.

The part of the barometric sensor altitude curve during rocket motor trust (between 2.2 and 4.0 s) is not correct because the rocket motor trust influences the pressure, but after 4 s, when the motors have burnt out, it is reliable.
The GPS altitude only shows a decent increase with small steps up to 17.5 m and starts decreasing again when the rocket on the parachute is at about 10 m above ground.

It is clear that the GPS is not losing track; latitude and longitude values are not strange.
The minimum number of satellites tracked varies from 8 to 10. All GGA messages during the shown time interval show a fix.

However, it is obvious that the GPS altitude is incorrect during the most interesting parts of the model rocket trajectory. It seems to me that a very slow filter is applied on altitude data inside the GPS .

From my point of view this incorrect GPS altitude is related to the Telit JF2 functionality.
My main question: How can I get perhaps more noisy, but actual GPS altitude output?

7

General Discussion / Barometric Pressure Sensor / Wrong pressure and altitude output with TinyZero

« on: April 24, 2020, 04:46:03 PM »

Reuse of a sketch with standard BMP280 library files BMP280.cpp and BMP280.h on a TinyZero with Combo Sensor TinyShield gave instable pressure and altitude measurements.
It turned out that reading of the compensation parameters (in BMP280.cpp) goes wrong for negative BMP280 chip parameters.
The BMP280 datasheet states that 10 of the 12 parameters have to be interpreted as signed short (so signed 16 bit).
However in BMP280.h the related variables are declared as int.
This works well for TinyDuino, but for TinyZero int is 32 bit. This means that in case of TinyZero the negative values are read as positive ones (between 32768 and 65535), leading to wrong compensations, e.g. to barometric pressure even outside the interval of 800 - 1200 mBar.

Different solutions are possible:
- changing the declaration of the signed parameters from int to short (in BMP280.h). In this case also readInt has to be adapted in BMP280.cpp and BMP280.h.
- logging the parameters and including these as constants in BMP280.cpp. The normal parameter reading process in BMP280.cpp has to be blocked.
- check the read (signed) parameters for values > 32767 and if true reduce with 65536. This is only useful for TinyZero.

I have checked the two first solutions and both are working properly with TinyZero (and also with TinyDuino).
My preference is the first solution because it is correcting the real error.
However, the second one provides additional insight in the parameters of different BMP280 chips.

I think it would be good to update the BMP280 Arduino Library to avoid problems with TinyZero.