newRPL - can't restore to 39gs

[franco51]

(03-18-2019 04:24 PM)Claudio L. Wrote:  

(03-18-2019 03:49 PM)3298 Wrote:  While I have no knowledge about how USB works or how newRPL uses it, a size limit reminds me of VPN affecting UDP traffic by lowering the max size, which can lead to dropped packets because unlike TCP packets the UDP ones cannot be fragmented. Let me throw an idea at the wall and see if it sticks: Conceptually USB hubs and VPN have something in common in that they tunnel traffic ... Are you using a USB hub? If so, try a direct connection.
(The culprit may not actually be a size limit; slow transmission that causes long packets to not be received in entirety before a timeout is over would probably have similar effects. The primary suspects for such bottlenecks are of course devices that literally sit in the middle of the connection, but it might be a driver too since those sit in the software section of the line, so to speak.)

newRPL uses a standard HID interface, so there's fixed-size packets of 64 bytes. newRPL uses a couple of bytes to identify packet type and send a stream of tiny packets.
The code { « 1 1 + 2 2 + 3 3 + 4 4 + » } compiles to exactly 64 bytes in size, so it would require 2 packets (because a few bytes of overhead on each packet).
But back to the original problem, the first 4 letters "NRPB" are not arriving well, and that's the very first packet. I'm thinking it might have to do with Windows and its extra byte. I don't remember changing the version of libusb I used to build the sources, but perhaps this problem has always been there we just didn't catch it.

EDIT: By the way, using standard HID means there's no driver getting in the way.

It would be great if someone else could check this out please.

On my Win 10 system some behaviour is slightly different from my Win 7 system –
n USBRECEIVE on the real calc for { « 1 1 + 2 2 + 3 3 + 4 4 + » } causes an Invalid data notice from the real calc, and the link does not disconnect.

Other results are the same -
{ « 1 1 + 2 2 + 3 3 + » } is received okay on the real calc. Also, it seems that any length is handled correctly when sent to the virtual calc.

The difference in behaviours may suggest timing issues, at least in part.

The other error message I was getting: "Failed to send remote commands to newRPL Calc - serial number - version"

Finally, just to elaborate on the .nrpb file, opening it in Notepad++ I can see NRPB in plain text at the start of the content, followed by NULs, EOTs and so forth. (Notepad++ does see this file as a Normal text file).

BR
Frank