hyOzd / serialplot

Small and simple software for plotting data from serial port in realtime.

Home Page:https://hackaday.io/project/5334-serialplot-realtime-plotting-software

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

SerialPlot limits fixed or payload size frames to 255 or less bytes

GitDave99 opened this issue · comments

I really need to have frames that are longer than 255 bytes.

I really like the triggered frame mode, like an O'scope. But I need 400 bytes per channel, at least, and up to 6 channels max, 4 channels typical, 2 channels minimum.

Another issue, version 0.12 and 0.11; if in ASCII mode, which by the way cannot receive my ASCII data at all, except as a raw binary stream in SP, when I click on Simple Binary button, the program freezes up, may or may not recover and show the binary stream on the chart. May have to use Task Manager to kill SP in that case.

ASCII mode: I'm trying to test if I can use it to circumvent the frame limitations in Custom Frame mode (255 or less total bytes). Using any other terminal program, I can see my ASCII formatted data from my project. Yet in SP, in ASCII mode, no data received... in text window, no data... If I am in Simple Binary mode, in text window I see my ASCII data. But no graphs.

Sigh. I am beyond frustrated trying to find a solution.

Keep up the good work, aside from the frame limits, I'm really happy with your program!

Regards
Dave
PS. below is the Pic Basic Pro 3.0 routine I'm using to try to get ASCII working in SerialPlot. Binary data works fine but I need more, more bytes per frame!. As you can see, I've tried various permutations on the theme, to no avail. Binary works fine.

'###############################################
DBUG_DATA: 'USE THIS TO VIEW DATA ARRAYS OUTSIDE OF INNER LOOPS
DEBUG "A",",", "B" , "," 'FRAME START HEADER
'DEBUG "200" 'PAYLOAD OR BUFFER SIZE TO BE SENT CRAP, 255 IS LIMIT!
'DEBUG 255,255
'DEBUG 200
FOR INDEX = 0 TO 19'9
debug DEC SLEW_RATEL(INDEX)
DEBUG ","
debug DEC SLEW_RATER(INDEX)
'DEBUG ","
'DEBUG "\r", "\n"
NEXT
'DEBUG "\r", "\n"

RETURN

@GitDave99 I could increase the size limit that's not a problem.

But I have a question. Since you already send the frame size from the device, why don't you just send multiple frames? Frame size doesn't have to be same. For example if you need to send 400 bytes, you can send 2 of 200 bytes frames. From the perspective of SerialPlot it shouldn't make any difference.

Just remember, each frame should contain full pack of data for each channel. For example if you have 3 channels in 'uint16_t' format. Each frame should contain multiple of 3 * 2 = 6 bytes data. You can stop at 5 bytes and send the remaining 1 byte in the next frame.

Regarding the problem you had with ASCII mode. Can you share the raw data you captured with the terminal application. Maybe in a separate ticket? BTW ASCII implementation is very inefficient. Maybe that is causing problems.

Unfortunately SerialPlot doesn't properly document the "Custom Frame" format option. So let me clarify a few things.

First of all, frame isn't like a framebuffer. A frame isn't what you see on the screen. There is a separate buffer of what you see on the screen. Size of this buffer is adjusted from the "Plot" tab. It is simply called "Buffer Size". Data that is sent from the device is simply added to this buffer which works like a ring buffer. As it fills up we cut from the beginning which means buffer always stays at a constant size. BTW there is a separate buffer for each channel. This setting is the size for only one of the buffers.

When a frame is received, samples of different channels are separated and put into their respective buffers.

There is no 'trigger' behavior at the moment. If you see any triggering behavior it is by luck probably.

Now regarding the frame format, I think your code is mostly okay. But you misunderstood what frame size corresponds to. In your latest piece of code it seems like you used frame size as "number of samples per channel". Frame size is actually total payload. Let me give you an example; assuming your data type is uint16_t (2 bytes) and there are 4 channels. If you send 10 samples in a frame. Frame size should be set as 2 * 4 * 10 = 80.

Here is a picture that I draw previously that illustrates how samples should appear in a frame. But I think you already implemented that correctly. Please note that in this example there is no "frame size" byte. It is just set from the UI.

image


ASCII data format is fairly simple. Each line contains samples from all channels. Like this:

100, 200, 300
110, 220, 330
111, 222, 333
...

There are no headers etc. You can set the number of channels from the SerialPlot. Or if you set it to 0 it is determined from incoming data.

Filter by prefix, isn't a triggering mechanism. When you have to send some other information along with your data you can use this so that SerialPlot can separate actual data from other text.

@GitDave99 just trying to pin-point your issue:
Do you see anything in the TextView panel (after you check "enable")?
Is the text format correct as expected?
Are you sending end of line characters? Which ones?
Could it be a serial port configuration issue (baudrate, number of bits, parity)?
What serial adapter are you using to connect to your PC?
Does communication with your system require handshake/flow-control signals?
What about DTR/RTS state (are they enabled, do you need them to be so)?

@GitDave99 I've added support for 2 byte size field a4b820c

You can build it from master branch. Or if you are interested in testing a custom build, please let me know if you prefer linux or windows image.

serialplot_2byte.zip

This is an exe you can run directly. Please let me know if it works for you.

@GitDave99 regarding ASCII mode problems; can you post the ASCII data captured with a terminal application?

Text View panel doesn't show the raw data coming from the serialport. It shows the parsed data that is sent to plot buffers. If there is a problem with parsing it is normal for Text View panel to be empty.

@GitDave99 I agree just by looking at the screen it is difficult to figure what needs to be done. I plan to create some tutorials especially about the custom frame format in the future. I'm also thinking about how I can improve the GUI itself so that it is easy to understand.

Dealing with multiple bytes is easy if you let the compiler do it for you. For example using C I would do it like this:

uint16_t payload_size = 400;
send_byte(payload_size & 0xFF); // this sends the lower byte, masking probably isn't necessary
send_byte(payload_size >> 8); // this sends the higher byte

// or if I have a send function that accepts an array as parameter I would to it like this:
uint16_t payload_size = 400;
send_array((char*)&payload_size, sizeof(uint16_t);

@GitDave99 I think something went wrong in your email. Instead of email, can you post it on github directly.

@hyOzd,
My condolences

Hi,

This is an amazing software!

I don't understand why the "Fix Frame Size" is limited to 255 ?
(I am using SerialPlot 0.12.0 on Windows10 64bit).

@hyOzd Can you please remove that limit (and also increase the width of the input text so it can show like 8 digits)?
I see you increased it to 65535 but in my software it is still limited to 255.

  • I want to use it with HW that sends 4-byte "Frame Start" followed by 100k 16bit samples of 1-4 channels-
    (100000x2x4 so I need to set "Frame Start" to 800000).

Thanks and looking forward to test and report if it works!