RN2483 communication issue

1

I try to communicate to a LoStick over serial. When I communicate with the python mini terminal that is provided with the lostick repository I can control the RN2483 with no problem. When I try to command the RN2483 from a C++ program i continue to get invalid_param.
This makes me conclude that communication is received by the RN2483.

When I verify the data using a USB-UART-TTL converter and a logic analyser I see the command sys get ver\r\n correctly appearing with right speed, and settings (8N1).

My question is:

  1. Is anyone aware of some timing restrictions like delay when communicating with RN2483? I have not found any in the documentation other than with autobaud.
  2. Who can point me a working solution with lostick?

thanks

1 Like
2

There shouldn’t be a timeout.

Did you issue the command multiple times without closing and reopening the port to make sure there is no garbage generate by opening the port?

3

Doing serial communications correctly in C/C++ can be trickier than it at first seems. You might try some intermediate tests against pyserial, or even using ltrace or USB packet sniffing to see what is really happening.

In particular pay attention to things like line endings, and invalid assumptions about the chunks and timing with which responses will arrive.

Default assumption should really be that the issue is either in your code, or the beliefs about what exactly your code needs to do in order to accomplish a goal. Blaming the module would be appropriate only when you can demonstrate that the same operations differing only in a specific way (such as transmit timing) which should not matter are producing a different result, and your current debug efforts seem quite far from doing that.

4

Yes I did.

I captured the output with a logic analyser and it seems ok to me.
image

I have no idea where to go next.

5

Nice. :muscle: Not my cup of tea, but just in case it’s not a totally stupid idea: would it be possible to create the same image for the Python mini terminal?

1 Like
6

Ok here is the capture of miniterm:
image
Be aware, the capture is truncated but has all info

7

Hmmm, yes, I’d say that looks the same, including the total time of about 2 ms.

timing

The vertical scale differs, but I guess you understand that difference?

And we’re seeing sys get vdd versus sys get ver, but I’d also not expect the first to throw invalid_param, and I guess you tried other commands from C++ as well?

8

The effect of copy and paste

Currently I can reproduce the same problem with putty. With putty after de CR I have to enter ctrl-J to produce a newline char. this results in invalid_param.

9

And PuTTY works fine when enabling “Implicit LF in every CR” in its Terminal options?

10

NO :rage:

11

Are you sure that only sends the new line? Not a CR as well? Which would be the invalid character at the start of a new line with a command?

I would like to see both this command and the last few characters from the previous line to see if anything there causes the issue.

12

Maybe that’s actually only for server-side CR, hence not adding a LF when you press Return in PuTTY. Or maybe not. Sorry if I caused confusion there…

13

My problem is that all my captures with the logic analyser are on a USB-TTL-serial converter, not on the actual lostick. I cannot access that hardware now. the problem occurs as soon as I use the lostick.

I just verified that both my dongle and the lostick use CH340T_SSOP20.

14

And your non lostick hardware works as expected with the correct response? Or is there no rn2483 connected to your serial converter?

1 Like