Closed K4KDR closed 7 years ago
Partially. The values displayed in the log file included in the issue post are what was decoded. Some are nominal and others obviously not.
The screen print included in the issue post also reflects the same values.
Appreciate the great work and progress!
=============================================================
On Mon, Apr 24, 2017 at 7:29 PM, James Mason notifications@github.com wrote:
Did the first packet that came through decode with correct values?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/jmason86/MinXSS_Beacon_Decoder/issues/13#issuecomment-296849816, or mute the thread https://github.com/notifications/unsubscribe-auth/AS9xIJOSonZybCD6H1POACMc6h5Ev6SEks5rzTBjgaJpZM4NGzlG .
Found part of the problem:
For decoding KISS I was doing something like this:
bufferData.replace(bytearray([0xDB, 0xDC]), bytearray(0xC0))
but that outputs to console. I needed to do
bufferData = bufferData.replace(bytearray([0xDB, 0xDC]), bytearray(0xC0))
.
But that is for some reason bloating the packet like crazy so I may need to do it in two lines of code, first find all instances of the KISS special characters ([0xDB, 0xDC]), then loop through and replace them with the value they mean ([0xC0]).
By the way I got your forwarded binary data and am looking at the hex, which is extremely helpful for this.
So I've got that working properly now (was just a minor typo that resulted in inflation, the replace does work). And I've figured out why the last few values still decode incorrectly: if the result is supposed to be negative, you'll end up with a bad decode. I'm working on handling negatives properly now. Slightly different than our existing IDL implementation since this is in python.
Try out the newest release! e92ebeb
Any better when you run old data through?
Looks like this issue did get solved. Closing.
Using commit 2d2887f, replayed recording from 21-Apr-2017 pass with high volume of packets. It would appear that the app perhaps does not handle packets correctly if the packet size is not what is expected. (??)
Also please note that some displayed values are well out of the expected range - perhaps a cause/effect of the error in handling the unexpected packet size? OR, it could be the reverse... BECAUSE the (incorrectly) decoded values are so very large, there could be a calculation in the code that adds all that up to be a packet that is larger than expected. Afraid I don't now whether packet size is measured by raw bytes or decoded values.
After first packet was decoded (and values displayed in the app), no further packets were decoded. The log file shows as follows: