Encoded raddecs over 50001 not accepted about hlc-server HOT 2 CLOSED

Hi @thomaskoerfer, thanks for raising the issue.

Typically, the remote device will run only barnowl (not barnacles) and forward the raddec stream. For an example see our tessel-edge code.

Will take a look why the toString() conversion would need to be utf8 rather than hex and provide feedback on this thread.

The issue with the method in the barnacles raddecmanager failing is known, although at least one fix was made over the past months and the issue is rarely observed. Will also take a look.

If the clocks on the remote and central devices are not well synchronised, it may be necessary to use the barnacles option "acceptStaleRaddecs": true. Please advise if this corrects the issue in your case.

from hlc-server.

Many thanks - this was super helpful. Some assumptions were simply wrong, which got clarified with the code example:

• re toString() - I didn't expect the hlc-server would expect an encoded Raddec transformed to a Binary hex. That is "Hex^2". Hence my assumption to convert it to utf-8 on the hlc-server end
• I didn't find it documented anywhere that the barnowl raddecs would need to be send over straight. Hence very helpful hint. I only wonder whether is network-friendly or whether that could be optimized
• Beaver on the hlc-server would only pick up the raddecs if I would switch on the options to include packets and timestamps. Something which I didn't get from the docu

After all - got everything working. Hence closing the issue

from hlc-server.