Closed CBielstein closed 2 years ago
so does it mean we need to have a better approach of handling the timeouts or is there a general practice around setting that time?
@eddywine It's starting to look like that. I suspect the error is in how I'm computing timeout in the test code since the actual decode is only taking milliseconds... if it keeps causing an issue and needing to be bumped up, we'll have to address it more directly, I suppose.
Description
The last of the remaining scenarios in the
PositionInfo
code is decodingPacketType.PositionWithoutTimestampWithMessaging
. This PR resolves that issue.Along with #109, this should allow APRS# to encode and decode any complete weather reports and position packets.
This was a pretty straightforward change as most of the code was already implemented. I added some encode and decode tests (encode of this already worked, only decode needed fixing, but more tests are always good!).
All that was left was to merge the "without timestamp" cases of position decode and set messaging support based on the packet type. This pattern follows the decode of the "with timestamp" types just below in the same file.
This will resolve #92.
Changes
PacketType.PositionWithoutTimestampWithMessaging
PositionInfo.cs
to support decode ofPacketType.PositionWithoutTimestampWithMessaging
Validation