no_std

[hargoniX]

The crate should become no_std as things that use NMEA directly are often gonna be embedded devices. #13

[elpiel]

#15 was closed in order for the changes to be split into smaller chunks.

What is the current status of the no_std support?
Is there something I could help with or maybe we can look for new contributors?

[Dushistov]

What is the current status of the no_std support?
Is there something I could help with or maybe we can look for new contributors?

The satellite part need help to work without alloc :

pub satellites: Vec<Satellite>,
pub fix_satellites_prns: Option<Vec<u32>>,
satellites_scan: HashMap<GnssType, Vec<Vec<Satellite>>>,

But before make any changes in that part we need tests for this part of nmea.
The tests were the main problem, as I rember, the are PR to replace HashMap or Vec or both (I don't remember),
but without tests it was hard to verify PR.

[elpiel]

Ok, so I see that there are a few tests with the parser that check the satellites but as far as I can see, they do so by testing one a single one.

What kind of test cases would be sufficient to test these out?

nmea/src/lib.rs

Lines 867 to 886 in c985682

	fn test_gsv() {
	let mut nmea = Nmea::new();
	// 10 07 05 08
	nmea.parse("$GPGSV,3,1,11,10,63,137,17,07,61,098,15,05,59,290,20,08,54,157,30*70")
	.unwrap();
	// 02 13 26 04
	nmea.parse("$GPGSV,3,2,11,02,39,223,19,13,28,070,17,26,23,252,,04,14,186,14*79")
	.unwrap();
	// 29 16 36
	nmea.parse("$GPGSV,3,3,11,29,09,301,24,16,09,020,,36,,,*76")
	.unwrap();
	assert_eq!(nmea.satellites().len(), 11);
	let sat: &Satellite = &(nmea.satellites()[0]);
	assert_eq!(sat.gnss_type, GnssType::Gps);
	assert_eq!(sat.prn, 10);
	assert_eq!(sat.elevation, Some(63.0));
	assert_eq!(sat.azimuth, Some(137.0));
	assert_eq!(sat.snr, Some(17.0));
	}

[Dushistov]

What kind of test cases would be sufficient to test these out?

Because the idea is to replace containers, the test should at least validate that all satellites which were mentioned in nmea stream
exists in struct Nmea after parsing, not just one random. Plus if implementation handle different kind of satellites in different ways, for example fixed array of length 32 for GPS and another fixed array of length 24 for GLONASS then we need nmea stream(s) with two satellites systems.

[elpiel]

Tests

What kind of test cases would be sufficient to test these out?

Because the idea is to replace containers, the test should at least validate that all satellites which were mentioned in nmea stream exists in struct Nmea after parsing, not just one random. Plus if implementation handle different kind of satellites in different ways, for example fixed array of length 32 for GPS and another fixed array of length 24 for GLONASS then we need nmea stream(s) with two satellites systems.

I asked a friend if he can provide some real examples/data since he has a boat and was recently tinkering with such packages, I believe it was NMAE.
Since there aren't such tests right now if I understand correctly, does it make sense to do the refactor anyway and make an issue to outline untested scenarios?

As for the tests, they can specifically mention that they don't cover these scenarios and maybe even link to the tracking issue.

I would say that having no_std can come before supporting/covering with tests these particular features.
Also, is the parser handling different GNSS right now?

More test examples

I found this link that, I believe has examples with multiple SVs in view, is this what we're looking for?

https://receiverhelp.trimble.com/alloy-gnss/en-us/NMEA-0183messages_GSV.html

[Dushistov]

Also, is the parser handling different GNSS right now?

Long time ago I tested this functionality manually and it works correctly.
I compared gpsd result of parsing and this rust crate results. Unfortunately all nmea logs
are lost since then.

It should be not hard to restore results, any modern Android phone can provide nmea data,
and uses at least GPS and GLONASS. But I will be busy in the next two months.

[elpiel]

I would say that this is not mandatory for the no_std support.
I'll see if I can work on the no_std support and the test coverage can be left for the #11 issue.

I will check how you get sentences from Android as well.

[elpiel]

Back to the question of how can we make the crate no_std?
I've already took look at array_vec (and const generics) and ahash (AHashMap) for possible solutions but I'm not really comfortable trying to refactor big chunks of the code.

I think we can focus on a few parts only, in particular, we can start with the Satellites, which use HashMap<_, Vec<Vec<_>>> and is a lot of nesting.

[Dushistov]

I removed HashMap, for 4 possible value of key it is not worth it.

So actually, to remove dependency from std::collection* there is need to calculate maximum number of visible
satellites. I know that for GPS it is 32, for GLONASS 24, but have no idea about Beidou, Galileo.

After that all Vec and VecDeque related to showing constellation of satellites is possible to replace with corresponding heapless::* containers.

And in GSA parsing there is usage of Vec, but only fields 3-14 can contains PRN number,
so it should be rather simple to replace with heapless::Vec because of capacity is known, I mean 14-3+1

[elpiel]

Well from wikipedia:

• Beidou has a total of 48 satellites (https://en.wikipedia.org/wiki/List_of_BeiDou_satellites) so I guess putting 48 as the limit should be more than sufficient (some of them are even retired)
• Galileo - From most locations, six to eight satellites will always be visible - https://www.esa.int/Applications/Navigation/Galileo/Galileo_a_constellation_of_navigation_satellites - so we can put a maximum of 16