PyTrack 2.0 soooo close!!
After struggling for so long with the first version of the Pytrack aquiring GPS with the supplied passive antenna and no external antenna option, I was thrilled to see a version 2 come out... But what's this?! An SMA connector?!
Why. Can anyone explain this decision? Everything else is u.fl! No chance of building a compact package now with a great big SMA poking out of the side.
So close to being the perfect tracking expansion board.
@Fred I haven't seen a schematic so I can't really comment on the performance gains you are referring to but unless i've missed something any circuitry before the connector (SMA/MMCX/u.fl or otherwise) is in most cases independant of what it's connecting to. From what i've seen there's already a manual active antenna switch in the form of a jumper (AON?) which negates the need for any electronic switching mechanism, unless you mean for the internal/external antenna feed, in which case i would have thought doing away with the passive onboard module altogether would have been the solution as in 'real world' conditions it's use is very limited. Perhaps you can clarify, I may be getting the wrong end of the stick here.
@Gijs @jcaron Thank you for your recommendations, I had considered MicropyGPS before starting this thread as i've had a fair amount of experience with it in the past, however it doesn't seem to play nicely on Pycom modules and causes it to crash (also as a frozen module). Regardless, as the dump_nmea() function simply prints the sentence it can't be used to feed the update() function within MicropyGPS. If i get a spare few minutes I'll write some stuff for the Pycom lib, in the mean time i'll have a go with L76GNSV4 :)
@wrm Very good point... believe me, we take form factor as one of the most important variables when designing new products... yep I don't like the size of the connector but here its about performance. Using an electrical switch would have introduced too much loss and our developers would have been complaining of poor GPS acquisition. Thanks
Thanks, I forgot about those!
In the meantime, I had some free time to experiment with my
speed_heading()function addition, its not that hard to write them yourself :-). Note that all I did was take the
coordinates()function and rewrote it. Corresponding with the L76 datasheet from here: https://docs.rs-online.com/4617/0900766b8147dbe5.pdf to get the correct NMEA message fields. This will give speed in km/h and heading in degrees true.
def speed_heading(self, debug=False): heading, speed, debug_timeout = None, None, False if self.timeout is not None: self.chrono.reset() self.chrono.start() nmea = b'' while True: if self.timeout is not None and self.chrono.read() >= self.timeout: self.chrono.stop() chrono_timeout = self.chrono.read() self.chrono.reset() self.timeout_status = False debug_timeout = True if not self.timeout_status: gc.collect() break nmea += self._read().lstrip(b'\n\n').rstrip(b'\n\n') gpvtg_idx = nmea.find(b'GPVTG') if gpvtg_idx < 0 and gpvtg_idx >= 0: gpvtg = 0 if gpvtg_idx >= 0: gpvtg = nmea[gpvtg_idx:] e_idx = gpvtg.find(b'\r\n') if e_idx >= 0: try: gpvtg = gpvtg[:e_idx].decode('ascii') gpvtg_s = gpvtg.split(',') heading = gpvtg_s speed = gpvtg_s except Exception: pass finally: nmea = nmea[(gpvtg_idx + e_idx):] gc.collect() break else: gc.collect() if len(nmea) > 410: # i suppose it can be safely changed to 82, which is longest NMEA frame nmea = nmea[-5:] # $GNGL without last L time.sleep(0.1) self.timeout_status = True if debug and debug_timeout: print('GPS timed out after %f seconds' % (chrono_timeout)) return(None, None) else: return(speed, heading)
@wrm Note that there are other libraries you can use. You'll find a couple at the bottom of this page:
@Gijs They should probably be added to the PyTrack 2.0 page as well, though.
https://github.com/inmcm/micropyGPS provides speed, heading, altitude, time and date, sat data, and more.
https://github.com/andrethemac/L76GLNSV4/blob/master/L76GNSV4.py provides speed, altitude, time and date...
Remember that the L76 outputs standard NMEA data, so there are probably even more suitable libraries.
I do like your ideas and I will propose them to the development team! If they're not up for it, I might be able to add some of your suggestions if I have some time to spare! In the meantime, you can use the
dump_nmea()function to get additional data! Note that you can also contribute to the libraries by submitting a PR to the repo on github ;) https://github.com/pycom/pycom-libraries
Hi Gijs, thanks for your reply,
If that's the case then fair enough, although I'm not convinced this couldn't be done with a u.fl connector. Size is definitely a consideration as you'd save probably over 10mm in width (haven't measured), but also the wide variety of GPS/GNSS antennas out there that only come with a u.fl connector. Another reason is connector placement within a case, using a u.fl to SMA tail makes this easy if an external antenna is needed.
I guess the main frustration for me is having recently designed a smaller expansion board of my own for the Pycom modules to address the lack of active/external GPS & SD card, as well as some other minor tweaks, I'd held off getting it manufactured after hearing 2.0 was on the horizon.
As a side note would you happen to know if there are plans to expose further GPS measurements in the pytrack library such as speed, heading, altitude, number of days, etc?
I was not involved in the design in any way, but I believe the decision was made around the SMA connector allowing the switching of internal to external antenna internally, so we wouldnt use an additional pin there. We do have an external SMA-connected antenna in the webshop that you can attach to this, but I do indeed understand you might have a size limitation there :(