Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - WillemH

Pages: 1 2
1
Réna,

many thanks for providing the schematic.

It is clear now that the SPI related ChipSelectN is connected to I07 and the CE to I09.

In my project the 2.4 GHz radio was working well, but the MicroSD was not.
Even without radio functionality in the code the microSD was not working anymore, when the NRFL01+ 2.4 GHz Radio Shield was connected to the bus.

This has been solved by just securing the SPI bus before
 
    SD.begin(chipSelect)

by setting  I07 (ChipSelectN of the NRF24L01+ radio) as output and making it high.

So adding the following code at the start of the setup:

   pinMode(7, OUTPUT); 
   digitalWrite(7, HIGH);

This was sufficient to solve the problem.
Doing the same with the ChipSelectN of the microSD (I10) does not harm, but is not strictly necessary.


Regards,
Willem

2
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

3
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

4
General Discussion / Re: GPS shield
« on: December 14, 2020, 04:14:54 AM »
For the technical answer please refer to my earlier post “GPS TinyShield does not provide actual altitude” on this forum.

Quote
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"
Unquote

Regards,
Willem

5
General Discussion / Re: ZOE GPS proto board / ZOE setup with examples
« on: December 14, 2020, 03:58:19 AM »
Hi Ben,

with respect to existing examples of Arduino code to interface with u-blox modules I would like to mention the “Sparkfun Ublox Arduino Library”. This large code package is much more focused on the I2C interface than the UART, but it can provide some learning experience with the u-blox GNSS receivers.

If you plan to use the ZOE-M8Q instead of the ZOE-M8B, it means that the “normal” SPG 3.01 firmware version is applicable, so some peculiar default settings related to the “Super-E mode” of the ZOE-M8B have gone. This means that adaptation of power mode setup (PMS) and change of CFG-GNSS to include SBAS can be skipped.

If I am right, it also means 3.3 V supply instead of 1.8 V, so perhaps the level shifter could be left out.
If you include the ZOE-M8Q, is it perhaps possible to provide access to the I2C pins?
With my model rocket application with UART only I have shown that it is not strictly necessary to have access to the I2C, but access to both UART and I2C will certainly increase the attractiveness of the new board.

Regards,
Willem

6
General Discussion / Re: ZOE GPS proto board / ZOE setup with examples
« on: December 03, 2020, 07:39:36 AM »
Herewith the  5th attachment containing the first part of a logging on microSD as example of an output file.

Regards
Willem

7
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 8), 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

8
In the mean time I also found that SBAS (Satellite-based augmentation system) is not enabled by default in the ZOE-M8B 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 corrections.

In the ZOE-M8B datasheet (ZOE-M8B_DataSheet_(UBX-17035164).pdf),  it is stated “Tracking SBAS satellites uses power and requires a long decoding time. It is recommended to disable SBAS for Super-E mode.”
Default disabling SBAS is in line with other default settings of the ZOE-M8B to minimize power consumption like the “Super-E mode”.

In a following post about changing the ZOE configuration using the UART channel (in preparation), I will also include how to enable SBAS.

Regards
Willem

9
Hi John,

yes, it is possible to get data from my test flights.

Please send me an e-mail (see members list) with an indication of the planned use.

With respect to BMA250 range and bandwidth, I used +/- 16 G to avoid saturation and BW 31.25 Hz (update time 16 ms).

The LSM9DS1 accelerometer is using much more bits, also + / - 16 G setting and ODR 50 Hz.

Just a note:

Because the model rocket fincan has canted fins, it also rolls (along its length axis) with a rotation rate depending among others on the forward velocity . This offers the possibility to test the gyro and the magnetic sensors.

The accelerometers are not positioned at the center, so the roll rotation also gives a significant centripetal acceleration to AccY and AccZ of BMA250 and AccX of LSM9DS1.

AccX of BMA250 and AccY of LSM9DS1 provide data of the forward acceleration of the model rocket including the rocket motor activity.

Regards,
Willem

10
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.

11
General Discussion / Re: GPS TinyShield does not provide actual altitude
« on: October 02, 2020, 05:25:06 PM »
Hi Ben,

thanks for your offer.
It will be great to test out such a compact solution, especially in a model rocket application.

Many thanks again,

Willem

12
General Discussion / Re: HW UART for GPS logging with TinyZero
« on: October 02, 2020, 05:04:21 PM »
Hi Ben,

many thanks.

You are right, crossing Tx and Rx is also necessary for the use as 'USB to UART Bridge'.

I think I will go for a HW solution: an additional temporary cross in the wiring, because the connection to the external GPS units I currently use is through a protoboard with wiring to connectors.

Many thanks again,

Willem

13
General Discussion / Re: GPS TinyShield does not provide actual altitude
« on: September 26, 2020, 09:44:23 AM »
Hi Ben,

Thanks for your answer.

The new TinyScreen+ board you mention sounds interesting.

Especially, the choice of a u-blox 8th generation GPS is fine because of the large reconfigurability, e.g. dynamic model, combination of GNSS constellations etc. Reconfiguration can be done by sending a series of ubx messages or preferably by using the nice environment of u-center, that translates those rather complex messages for the user.

It is therefore essential that the planned ZOE-M8B GPS will have the possibility for an off-line UART-USB connection to a PC with this u-center programme. It is also essential that the chosen configuration can be kept in internal GPS back-up memory for some time using a  back-up battery.

The combination with LSM9DS1, BME280, and microSD slot provides a compact solution.

Assuming that the GPS antenna is not mounted on the board itself, this new TinyScreen+ board could be placed vertically in many model rockets even with small diameter, down to 35 mm. In case of horizontal position it can be applied with outside diameter down to 42 mm.

I am currently preparing the integration of a Mateksys M8Q-5883 GPS board, a 20 x 20 mm board with the u-blox SAM-M8Q GPS, which also includes the 15 x 15 GPS patch antenna. This is the smallest board with this M8Q-5883GPS I have found.
Connected through a Tiny Shield protoboard, the package with TinyZero, Combo Sensor TinyShield and MicroSD TinyShield will fit in a 35 mm diameter model rocket with the GPS antenna looking upwards.

Willem

14
General Discussion / Re: HW UART for GPS logging with TinyZero
« on: September 25, 2020, 04:36:07 PM »
Hi Ben,

many thanks for your fast and very helpful response.

I clearly overlooked 'Serial', because I thought it only related to the serial monitor for the Tinyduino.
In the mean time I have done quick tests with HW UART with baud rates of both 19200 and 38400 in my high load GPS logging application.
Conclusion: 'Serial' works fine and a higher baud rate is possible than with 'SoftwareSerialZero'.

So, many thanks again.

Willem


Perhaps a directly related question, because the potential use of a USB Tiny Shield in case of a TinyZero processor is not completely clear for me:

Is it possible to use an additional bus-connected USB Tiny Shield as 'USB to UART Bridge' between PC and GPS for such  a GPS UART channel pinning (IO0 as RX (at Processor-side), IO1 as TX ) in case  a  non-interfering code is running on the TinyZero (e.g. Blink)?  I also assume that the TinyZero USB connection is not used at the same time.
Such a temporary PC-GPS connection is very useful e.g. to check and reconfigure a u-blox GPS with the programme u-center.

Or do I overlook some unwanted effects?

15
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.

Pages: 1 2
SMF spam blocked by CleanTalk