Messages

16

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

17

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?

18

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.

19

General Discussion / Re: GPS TinyShield does not provide actual altitude

« on: August 27, 2020, 09:03:29 AM »

Herewith the results of a vertically oriented trajectory trial with the u-blox SAM-M8Q GPS instead of the Telit JF2 GPS.

The u-blox SAM-M8Q GPS on the Sparkfun GPS 15210 board is connected to a TinyZero set through a proto shield (both I2C and UART). The set consists of a TinyZero Processor Board with accelerometer,  a MicroSD TinyShield , a Barometric Pressure TinyShield and on top the proto shield.

I have chosen to control the GPS settings through I2C and to use a selection of NMEA strings as output through UART set at 19200 baud rate. Using two separate buffer memories the NMEA strings are recorded in a .txt file and accelerometer outputs, barometer 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 (separate strings for GPS and GLONASS) and VTG strings at 5 Hz. The dynamic platform model of the GPS is set to nr 8: “Airborne <4g”, with e.g. maximal vertical velocities up to 100 m/s.

The setup of the trial was comparable with the one as described earlier, but now with an additional barometric pressure sensor in the nose cone of the model rocket, MER-75 with a 75 mm diameter.

The trial was executed on August, 15 near Almere, The Netherlands, with a surface height of -6 m with respect to sea level. Readings of the Altimeter 2: Apogee: 111 m, altitude at parachute ejection: 109 m above ground level.
The attached figures show some results of the trial.

The first figure shows the latitude, longitude and altitude of the trajectory derived from the NMEA GGA strings and transformed to xyz in m with the launch position as origin. Spheres are in red before ejection of the nose cone / parachute and in blue after. The second figure provides the top view, so xy only in m. The third figure vertically shows the altitude (in m) derived  from the barometric pressure sensor (now the one in the nose cone) and the u-blox SAM-M8Q GPS for the time interval including model rocket launch, boost phase, ballistic phase, nose cone / parachute ejection etc up to landing. The horizontal axis shows the time in milliseconds.

While the acceleration during launch shows a short peek > 4g, the GPS was not losing track ; outputs look fine.
The number of satellites tracked during the trajectory was constantly 12. All GGA messages during the shown time interval showed a Differential GPS fix.

As can been seen in the third figure the altitude values from GPS and barometric pressure sensor are rather close to each other. The GPS curve is very smooth, but altitudes before and after the trajectory differ more than the expected order of 1m, presumably because of noise.

In contrast with the Telit JF2 GPS, the u-blox SAM-M8Q GPS on the Sparkfun GPS 15210 board provides actual and useful altitude outputs.
As mentioned before, the major drawback is the large size of the Sparkfun breakout board, approx. 41 x 41 mm, which does not enable application in smaller diameter model rockets.

20

General Discussion / Re: GPS TinyShield does not provide actual altitude

« on: August 12, 2020, 11:21:25 AM »

Hello Laveréna,

It would be nice to find a fix for the JF2, because it is a nice small solution.

In the mean time I am experimenting with the Sparkfun GPS 15210 connected to a TinyZero set through a proto shield. This Sparkfun board has a very flexible GPS:  u-blox SAM-M8Q. In fact it is a GNSS with default GPS and GLONASS and features e.g. different dynamic platform models. Only drawback is the large size of the Sparkfun breakout board.  The SAM-M8Q GPS chip including patch antenna is small, only 15.5 x 15.5 x 6.3 mm. Perhaps it would fit on a bit higher TinyShield. That it is higher would not be a problem, because it is logical to use it as top shield because of the antenna.

The Telit “JF2 Hardware User Guide” can be found e.g. by Google using the search term “JF2 Hardware User Guide”.

Two results in the top 10 give access to this pdf document Rev.4 from 2013-04-09, links:
 
https://media.digikey.com/pdf/Data%20Sheets/NAVMAN%20Wireless%20PDFs/JF2_Hardware_UG.pdf

https://www.manualslib.com/download/1573008/Telit-Wireless-Solutions-Jf2.html

In the top 10 there is also a link for r5 (Rev. 5 I assume) to the Telit download zone, but that is only for direct Telit customers, and I am not. Perhaps TinyCircuits is a direct customer.

I hope this information is useful.

Willem

21

General Discussion / Re: GPS TinyShield does not provide actual altitude

« on: August 06, 2020, 10:25:29 AM »

In the mean time I have found another Telit JF2 GPS related document on the web, “JF2 Hardware User Guide”, in which it is mentioned in paragraph 11.6.3:

“By default, the JF2 will compute a 2-D solution when possible when performing initial acquisition. In a 2-D solution, the receiver assumes a value for altitude and uses it to estimate the horizontal position.” And also

“To accommodate applications for which these situations are a concern, a version of JF2 firmware is offered that requires a calculated altitude, i.e. a 3-D navigational solution, in order for the receiver to first enter navigation.”

So in fact it is stated that the JF2 by default does not directly calculate the altitude, but basically only a 2D solution instead of a 3D solution. However, the GPS fixes coming from the JF2 are indicated as 3D. I think that this 2D solution based process is the root cause of not providing the actual altitude in a dynamic vertical oriented trajectory.

It is also stated that another version of JF2 firmware is offered that provides a 3D solution. Can TinyCircuits provide this alternative JF2 firmware?

22

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?

23

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

« on: May 12, 2020, 07:57:55 AM »

Just an additional remark.

It would be logical that other SAMD based processors than TinyZero could have given comparable wrong pressure and altitude results in case of negative BMP280 chip parameters.

For instance, for the problem described as ".The altimeter readings I get on the barometer are totally different on the TinyScreen+ and make no sense. "  in "Skydive Altimeter on TinyScreen and Tinyscreen+ ", see User Projects / Code examples September 17, 2018, this probably has been the main cause as the SAMD of the Tinyscreen+ also has 32 bit int.

So the recent update of BMP280.h and  BMP280.cpp should also solve this problem.

Willem

24

General Discussion / Re: TinyZero Problems

« on: May 04, 2020, 06:27:43 AM »

Hello John,

after several successful uploads to a TinyDuino I experienced big problems with upload to a TinyZero.

Looking for a solution to a completely different problem, i.e. reading out a modern digital recorder, I found that the USB channels of the computer platform I worked with are relatively slow.

After using another computer platform with faster (more modern) USB channels I have got no problems anymore with upload to TinyZero.

Did you check if the USB channel you use for upload is fast enough?

Willem

25

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

« on: April 30, 2020, 11:02:56 AM »

Hello Réna,

Many thanks for pushing the code fix.
The updated BMP280 Arduino Library now gives stable results for both TinyZero and TinyDuino with comparable output for two different shields with BMP280.
So issue has been solved.

Willem

26

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

« on: April 27, 2020, 04:54:48 PM »

Réna,

thanks for your reaction.
Herewith the code related to the first solution
(- 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.)

In fact only three changes in total related to change of signed parameters, two in BMP280.h and one in BMP280.cpp.
See attachments.

It is perhaps cleaner to change the declaration of the unsigned parameters too, but not necessary, so I have not included it.

Willem

27

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.