Closed donok1 closed 3 years ago
The way that the --hex-output
functionality deals with bytes from the serial port is different from how they are handled otherwise. For normal output, each single-byte is decoded using UTF-8 encoding with an option to ignore characters that it is unable to decode (it ignores/drops bytes with decimal values 128-255).
If you replace the word "ignore" in this line of code with the word, "backslashreplace" what do you get from the output of your first command line?
Alternatively, try changing "utf-8" to "latin-1" in the same line of code.
Thanks @AlphaSierraHotel, this worked:
If you replace the word "ignore" in this line of code with the word, "backslashreplace"
After looking a bit more at the code, i noticed a few lines later that a condition is placed for writing in the output file.
In :
if out and out_char:
I removed the condition on out_char, and it worked as well, raw data being written without any check:
if out:
Please try the alternative mentioned above. I believe it should then work without removing the check for out_char (because out_char will then be a valid character). If it works, we can possibly put forward a pull request to add an option.
Sorry to not look at this sooner. In reviewing the situation here, I think it would be good to have a 'raw' mode for grabserial, that just passes the bytes through from input (the serial port) to output (stdout and the log) with no unicode decoding or encoding at all. (I swear I've spent more time messing with the unicode issues with grabserial than any other aspect of the code.) The 'hexoutput' mode essentially omits the unicode handling, but also has changes the output. I think it would be relatively straightforward to create the new 'raw' mode, and have hexoutput automatically use that mode, and restrict the hexoutput flag to just controlling the output formatting. What do you think?
I think we still need to do some decoding at least because we read a byte from the serial port and sometimes output it to stdout, a (string) text stream. I'd be happy to put together a pull request if you want. How would you feel about changing the default codec as a part of that?
I did a bit more troubleshooting (also fixed a RPi issue)
Please try the alternative mentioned above. I believe it should then work without removing the check for out_char (because out_char will then be a valid character). If it works, we can possibly put forward a pull request to add an option.
This worked. Using backslashreplace
worked well, without the need to remove the validity check.
I also needed to remove the exclusion of the carriage return by commenting those 2 lines, otherwise it would just be omit them in the output file.
After checking the data against a recording using an SD card and OpenLog, it all seemed complete.
Finally, I'm all new here:
create the new 'raw' mode, and have hexoutput automatically use that mode, and restrict the hexoutput flag to just controlling the output formatting. What do you think?
but I think I might not be the only one to appreciate a raw mode :)
Once I got it running at full speed, I noticed that grabserial was not keeping up on my RaspberryPi Zero. The reading and writing of 1 single byte at the time is not the most efficient, and then sleeping for 1 second can already fill the buffer.
So I built myself a little script, with a rudimentary adaptative sleep time to save power usage. I have a buffer of 4098 bytes. But it would still be nice to enjoy some of the grabserial feature, such like the rotating filename and so on
with open(output_filename,"wb") as myFile:
ser = setupSerial(GPSPort)
ser.reset_input_buffer()
ser.reset_output_buffer()
Twait = 0.01
y1=0
while True:
y = ser.in_waiting
if y > 50:
z=ser.read(y)
w = myFile.write(z)
else:
if y1 < 200:
Twait *= 1.3
elif y1 > 500:
Twait /= 2.5
time.sleep(Twait)
y1 = y
If there would be a simple way to integrate some sort of intelligent use of the buffer, that would help a lot in performance.
Also, while looking through the pyserial doc, I noticed that flushOuput
and flushInput
used here where renamed with v3.0+. To be replaced by reset_output_buffer()
and reset_input_buffer()
.
Sorry, I feel silly to do a PR just for that.
Stale issue message
Hi,
I'm trying to log raw data from my ublox GPS receiver on my raspberry pi using the UART serial port. Baud rate of 115200 and default 8N1 encoding.
The messages I expect to read should start with
B5 62 02 15
in HEX.I'm using the following command:
The output, once converter in HEX looks like this:
The message is not coming up, the B5 character
µ
(mu) never comes up.But when I add the
--hex-output
option, the hex file content seems to show the correct messages:I cannot explain it myself and could not find any option that would solve the problem.
Software version:
grabserial version 2.1.5
Python 3.7.3
Raspberry Pi 3 Model B Plus Rev 1.3
GNU/Linux Raspbian GNU/Linux 10 (buster)