Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Raise NotImplementedError when Operation field in packet 0x38 is set to 2 (load data) #26

Open
mjuenema opened this issue Oct 25, 2017 · 1 comment
Assignees
Milestone

Comments

@mjuenema
Copy link
Owner

Currently only requesting satellite data is (will be #25) implemented so the only valid value for the Operation field of Request Packet 0x38 is 1. Setting this field to 2, i.e. trying to load data into the satellite, should raise NotImplementedError (any other value will return an error from the GPS, correct?).

While I could implement loading data into the GPS I am (a) unable to test this and (b) don't want to "brick" my GPS ;-)

@mjuenema mjuenema added this to the 0.4.0 milestone Oct 25, 2017
@mjuenema mjuenema self-assigned this Oct 25, 2017
@mjuenema
Copy link
Owner Author

In fact only some GPS support loading of data. For instance the manual of the Thunderbolt-E says that this field must be set to 1.
Unfortunately the structure of the request body appears to vary between GPS. For Thunderbolt-E it is 3 bytes while the Copernicus II adds a 4th byte "length of data".

  • Does the Copernius II accept 3 byte requests?
  • If not, how could the code deal with it if the model of the GPS is not known?
  • Should one query the hardware version (0x1c) first and then format 0x38 accordingly?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant