ERROR: 0 bytes read in ReadUntilNBytesReceived trying to read 16 Error in getting header #250
Replies: 7 comments 6 replies
-
|
Addendum: my header is valid when I cut it out of the data, and the data is to spec, and even having separated calls to send the data and the header both wind up with the above message |
Beta Was this translation helpful? Give feedback.
-
|
Here’s the general layout… This code shows the right sizes for things. You seem to be passing 324 for your pixel count when you likely mean 300, which should be 0x12C, not 0x144
That’s my guess, anyway!
Element Length Purpose
Command 2 bytes Tells server what command you’re executing
Channel 2 bytes Which channel; can be 0 for all
Length 4 bytes Number of pixels you are requesting to set
Seconds 8 bytes Seconds of current time (can be 0)
Micros 8 bytes Micros of current time (can be 0)
Color Data Len*3 RGB color data
Command: 3, 0,
Channel: 0, 0,
Length: 44, 1, 0, 0 (324 pixels)
Seconds: 0, 0, 0, 0, 0, 0, 0, 0,
Micros: 0, 0, 0, 0, 0, 0, 0, 0,
255, 0, 0, 255, 5, 0, 255, 10, 0, 255, 15, 0, 255, 20, 0, 255, 26, 0, 255, 31, 0, 255, 36, 0, 255, 41, 0, 255, 46, 0, 255, 51, 0, 255, 56, 0, 255, 61, 0, 255, 66, 0, 255, 71, 0, 255, 77, 0, 255, 82, 0, 255, 87, 0, 255, 92, 0, 255, 97, 0, 255, 102, 0, 255, 107, 0, 255, 112, 0, 255, 117, 0, 255, 122, 0, 255, 128, 0, 255, 133, 0, 255, 138, 0, 255, 143, 0, 255, 148, 0, 255, 153, 0, 255, 158, 0, 255, 163, 0, 255, 168, 0, 255, 173, 0,
command = 3 # WIFI_COMMAND_PIXELDATA64 == 3
length32 = int(len(pixels) / 3) # Number of pixels being set
commandData = (command).to_bytes(2, byteorder='little') # Offset 0, command16
channelData = (1).to_bytes(2, byteorder='little') # Offset 2, LED channelID
lengthData = (length32).to_bytes(4, byteorder='little') # Offset 4, length32
secondsData = (seconds).to_bytes(8, byteorder='little') # Offset 8, seconds
microsData = (microseconds).to_bytes(8, byteorder='little') # struct.pack('d', microseconds) # Offset 16, micros
colorData = bytes(pixels)
header = commandData + channelData + lengthData + secondsData + microsData
complete_packet = header + colorData
… On Apr 5, 2023, at 7:57 PM, SturdyFool10 ***@***.***> wrote:
Addendum: my header is valid when I cut it out of the data, and the data is to spec, and even having separated calls to send the data and the header both wind up with the above message
—
Reply to this email directly, view it on GitHub <#250 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA4HCF3RCTA2GAM3WQC4W6LW7YWLLANCNFSM6AAAAAAWU2F5AE>.
You are receiving this because you are subscribed to this thread.
|
Beta Was this translation helpful? Give feedback.
-
|
as much as I do not want to be that guy, it would seem that NightDriver is getting the length correct at 300, seen in the second block of output in my first message, NightDriver is saying that the length it received is 300, likely from the header, to copy/paste it from the original message: |
Beta Was this translation helpful? Give feedback.
-
|
Are you certain you’re passing 900 bytes of color data? Remember it’s pixels, not bytes. Three bytes per pixel...
… On Apr 5, 2023, at 11:39 PM, SturdyFool10 ***@***.***> wrote:
as much as I do not want to be that guy, it would seem that NightDriver is getting the length correct at 300, seen in the second block of output in my first message, NightDriver is saying that the length it received is 300, likely from the header, to copy/paste it again (W) (ProcessIncomingConnectionsLoop)(C0) Uncompressed Header: channel16=0, length=300, seconds=0, micro=0 (W) (ReadUntilNBytesReceived)(C0) ERROR: 0 bytes read in ReadUntilNBytesReceived trying to read 16 (W) (W) (ProcessIncomingConnectionsLoop)(C0) Read error in getting header. (W) (W) (SocketServerTaskEntry)(C0) Socket connection closed. Retrying... (W) thank you for the help as at this point I really do need the extra sets of eyes on this one
—
Reply to this email directly, view it on GitHub <#250 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA4HCF5EBNK6347ZLYF2TDLW7ZQLFANCNFSM6AAAAAAWU2F5AE>.
You are receiving this because you commented.
|
Beta Was this translation helpful? Give feedback.
-
|
if I ask my codebase to output bytes.len()(Which is rusts length function) it yields: |
Beta Was this translation helpful? Give feedback.
-
|
Can you explain the 0x0144 value? I figure it should be 300, not 324. Not sure why the program still claims 300 reported, but that’s the only thing that stands out to me….
… On Apr 6, 2023, at 11:02 AM, SturdyFool10 ***@***.***> wrote:
if I ask my codebase to output bytes.len()(Which is rusts length function) it yields:
Packet Data: [3, 0, 0, 0, 44, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 255, 0, 0, ... 255, 0, 5], Packet Size: 924
in this case, the header is concatenated with the data, so 924 sounds right to me
—
Reply to this email directly, view it on GitHub <#250 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA4HCFYYXJZRRJG2SR3ITODW74AKJANCNFSM6AAAAAAWU2F5AE>.
You are receiving this because you commented.
|
Beta Was this translation helpful? Give feedback.
-
|
In this case, I am outputting the value of a byte array of type |
Beta Was this translation helpful? Give feedback.
-
|
I’ll believe you, but that’s a weird output format :-)
Assuming that’s right, then, did you confirm that 900 bytes of color data follow the header? From the debug output, all I can tell is:
1) It’s expecting 300 pixels after the header
2) It seems to be running out before it gets that many
2a) It says it’s reading 16 bytes which smells a little odd to me, I’d expect it to be reading 900
Also make sure you’re NOT sending the ‘DAVE’ header which is only for compressed frames. Doubt that’s an issue, just being thorough.
I wish my mail client preserved the entire thread!
- Dave
… On Apr 6, 2023, at 11:14 AM, SturdyFool10 ***@***.***> wrote:
In this case, I am outputting the value of a byte array of type Vec<u8> to the console using the format string "{:?}" which will naïvely display the list of unsigned 8 bit integers as numbers, or to be specific in decimal, 0x2C to decimal is 44 so that byte being 44, 1, 0, 0 means 300, or to break it apart, bytes: 0x2C, 0x1, 0x0, 0x0, which is reversed from rust's to_be_bytes function but this outputted the right number over serial in nightdriver's logs seen above: (W) (ProcessIncomingConnectionsLoop)(C0) Uncompressed Header: channel16=0, length=300, seconds=0, micro=0
—
Reply to this email directly, view it on GitHub <#250 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA4HCF3UWPFV34QJBV72ANDW74BY5ANCNFSM6AAAAAAWU2F5AE>.
You are receiving this because you commented.
|
Beta Was this translation helpful? Give feedback.
-
|
Yeah, I specifically asked during verification what the length of the byte array was, and including the uncompressed header it was 924 bytes long, so, 900 bytes of color data |
Beta Was this translation helpful? Give feedback.
-
|
STANDARD_DATA_HEADER_SIZE is 24, so that should be right.
I just tested the code from python and it worked perfectly, even for video, so unless it’s some weird edge case it’s still probably the client, but I can’t spot anything else wrong.
Best I can suggest is (a) write a 10-liner python version to make sure it works as you expect (you can make something quick from videoserver.py). If that works at your house as well as it does mine, it’s got to be the client.
If you’ve got a JTAG debugger you can try to debug it right in VSCode, but failing that, I’d add some more printfs to assert each and every bit of info as it reads it, and then the problem should become apparent no matter where it is!
totalExpected, around line 397 of socketserver.h would be a good place to start: in my code for some reason the expected size is in a debugE which should output every time, which is odd. But check what it’s expecting.
If it’s expecting 324 and you’re sending 324, then it’s even weirder, but I suspect it’ll be different.
Cheers,
Dave
… On Apr 6, 2023, at 3:45 PM, SturdyFool10 ***@***.***> wrote:
Yeah, I specifically asked during verification what the length of the byte array was, and including the uncompressed header it was 924 bytes long
—
Reply to this email directly, view it on GitHub <#250 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA4HCF7KH2HWTKTJCRT65WTW75BSLANCNFSM6AAAAAAWU2F5AE>.
You are receiving this because you commented.
|
Beta Was this translation helpful? Give feedback.
-
|
Ok, I’ll have to check it out later and I’ll try to have python send the packet to my ESP32 and see if anything changes, but just in case, how would you personally choose to configure a strip of 300 LEDS that should be basically always be receiving these packets? If I have to do a reflash I want to make absolutely sure I configure NightDriver correctly |
Beta Was this translation helpful? Give feedback.
-
|
As long as it’s less than about 1000 LEDs, doing them all on a single channel is fine. The more buffers you can allocate, the better your connection will be (with PSRAM I run 500, but without you can likely do 50 perhaps)? Set NUM_LEDS to 300.
… On Apr 6, 2023, at 6:06 PM, SturdyFool10 ***@***.***> wrote:
Ok, I’ll have to check it out later and I’ll try to have python send the packet to my ESP32 and see if anything changes, but just in case, how would you personally choose to configure a strip of 300 LEDS that should be basically always be receiving these packets? If I have to do a ref lash I want to make absolutely sure I configure NightDriver correctly
—
Reply to this email directly, view it on GitHub <#250 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA4HCF4RWT32DFHRC4NHFJTW75SB5ANCNFSM6AAAAAAWU2F5AE>.
You are receiving this because you commented.
|
Beta Was this translation helpful? Give feedback.
-
|
I decided to use ledstrip, and the same thing is happening, also, I did the googling and found the rust format string for hexadecimal representation, so here's the packet there: So, I've tried a few things: 1. I have tried omitting the colordata using a iterator to see that the header is valid, and the error changes from |
Beta Was this translation helpful? Give feedback.
-
I am having issues with my rust night driver wifi API and I can't even seem to nail down a reason, I have gotten everything to compile and run but while sending this packet:
[3, 0, 0, 0, 44, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 255, 0, 0, 255, 5, 0, 255, 10, 0, 255, 15, 0, 255, 20, 0, 255, 26, 0, 255, 31, 0, 255, 36, 0, 255, 41, 0, 255, 46, 0, 255, 51, 0, 255, 56, 0, 255, 61, 0, 255, 66, 0, 255, 71, 0, 255, 77, 0, 255, 82, 0, 255, 87, 0, 255, 92, 0, 255, 97, 0, 255, 102, 0, 255, 107, 0, 255, 112, 0, 255, 117, 0, 255, 122, 0, 255, 128, 0, 255, 133, 0, 255, 138, 0, 255, 143, 0, 255, 148, 0, 255, 153, 0, 255, 158, 0, 255, 163, 0, 255, 168, 0, 255, 173, 0, 255, 179, 0, 255, 184, 0, 255, 189, 0, 255, 194, 0, 255, 199, 0, 255, 204, 0, 255, 209, 0, 255, 214, 0, 255, 219, 0, 255, 224, 0, 255, 230, 0, 255, 235, 0, 255, 240, 0, 255, 245, 0, 255, 250, 0, 255, 255, 0, 250, 255, 0, 245, 255, 0, 240, 255, 0, 235, 255, 0, 230, 255, 0, 224, 255, 0, 219, 255, 0, 214, 255, 0, 209, 255, 0, 204, 255, 0, 199, 255, 0, 194, 255, 0, 189, 255, 0, 184, 255, 0, 179, 255, 0, 173, 255, 0, 168, 255, 0, 163, 255, 0, 158, 255, 0, 153, 255, 0, 148, 255, 0, 143, 255, 0, 138, 255, 0, 133, 255, 0, 128, 255, 0, 122, 255, 0, 117, 255, 0, 112, 255, 0, 107, 255, 0, 102, 255, 0, 97, 255, 0, 92, 255, 0, 87, 255, 0, 82, 255, 0, 76, 255, 0, 71, 255, 0, 66, 255, 0, 61, 255, 0, 56, 255, 0, 51, 255, 0, 46, 255, 0, 41, 255, 0, 36, 255, 0, 31, 255, 0, 26, 255, 0, 20, 255, 0, 15, 255, 0, 10, 255, 0, 5, 255, 0, 0, 255, 0, 0, 255, 5, 0, 255, 10, 0, 255, 15, 0, 255, 20, 0, 255, 25, 0, 255, 31, 0, 255, 36, 0, 255, 41, 0, 255, 46, 0, 255, 51, 0, 255, 56, 0, 255, 61, 0, 255, 66, 0, 255, 71, 0, 255, 76, 0, 255, 82, 0, 255, 87, 0, 255, 92, 0, 255, 97, 0, 255, 102, 0, 255, 107, 0, 255, 112, 0, 255, 117, 0, 255, 122, 0, 255, 128, 0, 255, 133, 0, 255, 138, 0, 255, 143, 0, 255, 148, 0, 255, 153, 0, 255, 158, 0, 255, 163, 0, 255, 168, 0, 255, 173, 0, 255, 178, 0, 255, 184, 0, 255, 189, 0, 255, 194, 0, 255, 199, 0, 255, 204, 0, 255, 209, 0, 255, 214, 0, 255, 219, 0, 255, 224, 0, 255, 229, 0, 255, 235, 0, 255, 240, 0, 255, 245, 0, 255, 250, 0, 255, 255, 0, 250, 255, 0, 245, 255, 0, 240, 255, 0, 235, 255, 0, 230, 255, 0, 224, 255, 0, 219, 255, 0, 214, 255, 0, 209, 255, 0, 204, 255, 0, 199, 255, 0, 194, 255, 0, 189, 255, 0, 184, 255, 0, 178, 255, 0, 173, 255, 0, 168, 255, 0, 163, 255, 0, 158, 255, 0, 153, 255, 0, 148, 255, 0, 143, 255, 0, 138, 255, 0, 133, 255, 0, 128, 255, 0, 122, 255, 0, 117, 255, 0, 112, 255, 0, 107, 255, 0, 102, 255, 0, 97, 255, 0, 92, 255, 0, 87, 255, 0, 82, 255, 0, 76, 255, 0, 71, 255, 0, 66, 255, 0, 61, 255, 0, 56, 255, 0, 51, 255, 0, 46, 255, 0, 41, 255, 0, 36, 255, 0, 31, 255, 0, 26, 255, 0, 20, 255, 0, 15, 255, 0, 10, 255, 0, 5, 255, 0, 0, 255, 5, 0, 255, 10, 0, 255, 15, 0, 255, 20, 0, 255, 25, 0, 255, 31, 0, 255, 36, 0, 255, 41, 0, 255, 46, 0, 255, 51, 0, 255, 56, 0, 255, 61, 0, 255, 66, 0, 255, 71, 0, 255, 76, 0, 255, 82, 0, 255, 87, 0, 255, 92, 0, 255, 97, 0, 255, 102, 0, 255, 107, 0, 255, 112, 0, 255, 117, 0, 255, 122, 0, 255, 128, 0, 255, 133, 0, 255, 138, 0, 255, 143, 0, 255, 148, 0, 255, 153, 0, 255, 158, 0, 255, 163, 0, 255, 168, 0, 255, 173, 0, 255, 179, 0, 255, 184, 0, 255, 189, 0, 255, 194, 0, 255, 199, 0, 255, 204, 0, 255, 209, 0, 255, 214, 0, 255, 219, 0, 255, 224, 0, 255, 230, 0, 255, 235, 0, 255, 240, 0, 255, 245, 0, 255, 250, 0, 255, 255, 0, 255, 255, 0, 250, 255, 0, 245, 255, 0, 240, 255, 0, 235, 255, 0, 229, 255, 0, 224, 255, 0, 219, 255, 0, 214, 255, 0, 209, 255, 0, 204, 255, 0, 199, 255, 0, 194, 255, 0, 189, 255, 0, 184, 255, 0, 178, 255, 0, 173, 255, 0, 168, 255, 0, 163, 255, 0, 158, 255, 0, 153, 255, 0, 148, 255, 0, 143, 255, 0, 138, 255, 0, 133, 255, 0, 128, 255, 0, 122, 255, 0, 117, 255, 0, 112, 255, 0, 107, 255, 0, 102, 255, 0, 97, 255, 0, 92, 255, 0, 87, 255, 0, 82, 255, 0, 77, 255, 0, 71, 255, 0, 66, 255, 0, 61, 255, 0, 56, 255, 0, 51, 255, 0, 46, 255, 0, 41, 255, 0, 36, 255, 0, 31, 255, 0, 25, 255, 0, 20, 255, 0, 15, 255, 0, 10, 255, 0, 5]to the nightdriver strip of 300 leds, which should yield a rainbow, it logs to the console:(W) (ProcessIncomingConnectionsLoop)(C0) Uncompressed Header: channel16=0, length=300, seconds=0, micro=0 (W) (ReadUntilNBytesReceived)(C0) ERROR: 0 bytes read in ReadUntilNBytesReceived trying to read 16 (W) (W) (ProcessIncomingConnectionsLoop)(C0) Read error in getting header. (W) (W) (SocketServerTaskEntry)(C0) Socket connection closed. Retrying... (W)Beta Was this translation helpful? Give feedback.
All reactions