search

jmason86 / MinXSS_Beacon_Decoder

Beacon decoder for the MinXSS CubeSat in space; MinXSS-2 launch on 2018-11-19
http://lasp.colorado.edu/home/minxss
GNU General Public License v3.0
11 stars 6 forks source link

ERROR Too many bytes in packet #13

Closed K4KDR closed 7 years ago

K4KDR commented 7 years ago

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:

2017-04-24 16:51:10,518 INFO Launched app
2017-04-24 16:51:10,519 INFO Opening binary file for buffer data
2017-04-24 16:51:23,826 INFO Attempting to connect to port
2017-04-24 16:51:23,827 INFO Opening IP address: 127.0.0.1 on port: 8100
2017-04-24 16:51:48,867 INFO Packet length [bytes] = 273
2017-04-24 16:51:48,879 INFO From MinXSS parser:
2017-04-24 16:51:48,880 INFO {'SolarPanelPlusYCurrent': 11280.245361328125, 'EpsBoardTemperature': 31.8125, 'SpacecraftMode': 4, 'SolarPanelMinusYCurrent': 14361.992797851564, 'EnableX123': 0, 'SolarPanelPlusYTemperature': 9964.4256, 'BatteryDischargeCurrent': 20898.6224, 'CommBoardTemperature': 22.625, 'FlightModel': 1, 'MotherboardTemperature': 6.125, 'CommandAcceptCount': 2867, 'PointingMode': 1, 'Eclipse': 0, 'BatteryTemperature': 5562.75616, 'BatteryChargeCurrent': 138365.4992, 'SolarPanelPlusYVoltage': 2.0484997558593747, 'SolarPanelPlusXVoltage': 6.146499023437499, 'BatteryVoltage': 7.0282151208106, 'SolarPanelPlusXCurrent': 3103.7420654296875, 'SpsX': 6.9888, 'SpsY': 19.275299999999998, 'CdhBoardTemperature': 11.0625, 'EnableSps': 1, 'SolarPanelMinusYTemperature': 55.19200000000001, 'Xp': 0, 'SolarPanelMinusYVoltage': 28.665999755859374, 'SolarPanelPlusXTemperature': -36.367999999999995}
2017-04-24 16:51:50,246 ERROR Too many bytes in packet
2017-04-24 16:51:50,247 INFO Packet length [bytes] = 501
2017-04-24 16:51:50,252 INFO No sync bytes found
2017-04-24 16:51:51,762 INFO Packet length [bytes] = 238
2017-04-24 16:51:51,772 INFO Closing ground station link

screenshot from 2017-04-24 16-52-48

K4KDR commented 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 .

jmason86 commented 7 years ago

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]).

jmason86 commented 7 years ago

By the way I got your forwarded binary data and am looking at the hex, which is extremely helpful for this.

jmason86 commented 7 years ago

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.

jmason86 commented 7 years ago

Try out the newest release! e92ebeb

jmason86 commented 7 years ago

Any better when you run old data through?

jmason86 commented 7 years ago

Looks like this issue did get solved. Closing.