search

stephenhouser / node-red-contrib-wsjt-x

A Node to handle the decoding of WSJT-X data in NodeRed.
Other
6 stars 0 forks source link

RangeError: Offset is outside the bounds of the DataView #9

Closed wz2b closed 9 months ago

wz2b commented 9 months ago

I just tried installing node-red-contrib-wsjt-x 2.0.1 and redirected my WSJT-X computer to send packets to Node-RED. It sees heartbeats just fine, but I see this:

"RangeError: Offset is outside the bounds of the DataView"

trying to decode this:

{
  "payload": [173,188,203,218,0,0,0,2,0,0,0,1,0,0,0,6,87,83,74,84,45,88,0,0,0,0,1,20,65,24,0,0,0,4,87,83,80,82,0,0,0,6,73,87,49,80,85,82,0,0,0,3,45,49,53,0,0,0,4,87,83,80,82,1,0,1,0,0,5,95,0,0,5,220,0,0,0,4,87,90,50,66,0,0,0,6,70,78,49,51,71,66,0,0,0,4,74,78,52,52,0,255,255,255,255,0,0,255,255,255,255,255,255,255,255,0,0,0,7,68,101,102,97,117,108,116],
  "fromip":"192.168.1.177:37420",
  "ip":"192.168.1.177",
  "port":37420,
  "_msgid":"9f9a3fd8c733b764"
}

The WJST-X that I am running is on a Linux computer, version 2.1.2 and it's in WSPR mode.

It decodes heartbeats correctly. In case the heartbeat content is helpful:

{
  "magic":2914831322,
  "schema":2,
  "type":"heartbeat",
  "id":"WSJT-X",
  "max_schema_number":3,
  "version":"2.1.2",
  "revision":""
}

Is there some version incompatibility here that I should be aware of?

wz2b commented 9 months ago

Working through a sample message:

173 188 203 218        WSJT-X message header
0 0 0 2                        schema number
0 0 0 1                        message number is 1, which is a "status" message

Next should be the ID field, which is a string
/* This is the ID field, a string / unique key
0 0 0 6  (length is 6)
87 83 74 84 45 88  (string is WSJT-X)

What should come next is the frequency, as a 64-bit unsigned int.

88 0 0 0 0 1 173 37

That is NOT a frequency.  I don't know what that 88 is in there.  But if you ignore that 88 you get this:

    0 0 0 0 1 173 37 184 = 28124600 = 28.1246 MHz which is correct (it's WSPR on 10m)

so I'm off the rails already, looking at the format HERE and HERE it seems like everythign is on track except that extra decimal 88 (hex 0x58) shouldn't be there ... HMMM

wz2b commented 9 months ago

Update: I think this whole problem is an ancient wsjt-x. And I think I have to upgrade my OS to fix that. Will update this ticket.

wz2b commented 9 months ago

Sorry. This ENTIRE problem was because I didn't realize my wjst-x was ANCIENT. I installed it with 'apt' on an Ubuntu 20.04LTS and it got an ancient one. I upgraded to version 2.6.1 and now it works and is completely happy Sorry for the false alarm, but I will leave this ticket here in case somebody else makes the same mistake I did.

If you expect version 2.1.2 to work then that's an actual bug, but I think it makes more sense to flat out not support ancient versions.

stephenhouser commented 9 months ago

Thanks for the issue. I do expect somewhat older versions to wok, though the focus is on more recent versions. I'm going to leave this open as a "might fix" but not a "definite needs to be fixed"

Again, thanks for the issue. I think there's enough in here to address it.