Serout2 question

Is there any switch/setting that can send everything in a serout2 command in the 1 complete packet?

eg
MyValue = 100
serout2 PORTB.1, 84, ["This is my value:", dec MyValue, 13,10]

can be sent out as a complete "This is my value: 100 CRLF"

The reason I ask is because there's one particular RF transceiver module I have that will only transmit the "This is my value". All my other transceivers will happily transmit the entire parameters including value, CR and LF. This is the same deal for all my serout2 transmits irrespective of string lengths.

I really want to avoid having to contract everything together into a single variable prior to sending.

I haven't tried sending using hardware, but if that's a solution, I can work with that.

The module is a CEbyte E22-400T37S

Thanks for any assistance.

Troy

The command serout2 PORTB.1, 84, ["This is my value:", dec MyValue, 13,10] is valid and you can use it.

Also same goes for Hserin too.

I may have not understood your problem.

Ioannis

Hi Ioannis,
The problem isn't with the validity of the code, it's more to do with... well... the combination of the transceiver and the way PBP sends the packet. So, for a statement like that:

serout2 PORTB.1, 84, ["This is my value:", dec MyValue, 13,10]

I would've assumed that the compiler would (behind the scenes) contract all that into a single string and send it all at once. But it doesn't appear to. It appears to send everything separated by commas as individual packets - one after another. What I'm guessing is happening is the 1st packet ie. the "This is my value:" string is sent to the serial port and on to my transceiver and whilst the transceiver is sending that off, the code is sending the next packet, which is the value converted to a string. So, it appears as though all subsequent packets from the original string are being discarded by the transceiver - perhaps because it's busy sending that 1st string? So, the result is I only get the original string transmitted "This is my value:" and nothing else - no value, no carriage return or line feed. Only happens with this particular module of transceiver.
I can't see any setting for the transceiver to adjust the receiving packet processing or delay, so I'm wondering if there's a switch or setting in PBP to send everything as one packet instead of separate individual packets within the 1 single command?

I'm really trying to avoid contracting everything into a single array via Arraywrite prior to every serout2 command.

Cheers,

Troy

The command send all at once. No commas are inserted if you do not explicitly define so.

The command will send the text string and immediately after that will send the MyValue not as one binary byte but as 1 up to 3 ASCII codes of the value.

Example 1. If MyValue is 5, the command as you stated will send

This is my value:5crlf

The above expressed in ASCII codes will be

Code:

---

$54 $68 $69 $73 $20 $69 $73 $20 $6d $79 $20 $76 $61 $6c $75 $65 $3a $35 $0d $0a
 T  h  i  s      i  s        m  y      v  a  l  u  e  :  5  CR  LF

---

Example 2. If MyValue is 123 then you send out

This is my value:123crlf

or expressed in ASCII codes

Code:

---

$54 $68 $69 $73 $20 $69 $73 $20 $6d $79 $20 $76 $61 $6c $75 $65 $3a $31 $32 $33 $0d $0a
 T  h  i  s      i  s        m  y      v  a  l  u  e  :  1  2  3  CR  LF

---

I think you have not used correctly ascii and binary values. Hope the above clears things for you.

Ioannis

Code:

---

serout2 PORTB.1, 84, ["This is my value:", dec MyValue, 13,10]

---

There's no "packet" created... bytes are streamed out the software UART as they are made ready.

There may be a small delay between the last char of "This is my value:" and the 'dec MyValue' portions because it takes time for the uC to convert the binary data to an ASCII string. How long that takes would depend on the uC, clock, and MyValue.

Quote:

---

Originally Posted by tumbleweed

Code:

---

serout2 PORTB.1, 84, ["This is my value:", dec MyValue, 13,10]

---

There's no "packet" created... bytes are streamed out the software UART as they are made ready.

There may be a small delay between the last char of "This is my value:" and the 'dec MyValue' portions because it takes time for the uC to convert the binary data to an ASCII string. How long that takes would depend on the uC, clock, and MyValue.

---

Okay, interesting. So that small delay might be triggering the RF transceiver to interpret the end of the packet. I'm running an 8mhz clock on a PIC18F26K83 so there is scope to play with clock speeds. I'll have a play.

Troy

Either one character or million of characters, the RS-232 sends each character alone. It has start bit, stop bit, maybe a parity bit too and the data itself. So, if between characters, there is small or big delay it should not matter, in most cases anyway.

You have to study carefully the modules you use if they need specific timings.

Some LORA modules I use seems to wait for a bit of time and if next character has not arrived in this time frame, sends the characters already in the buffer. Then the next characters are not lost but sent immediately after the previous transmission.

Now, what happens on the receiver side is the users responsibility to collect the data in good order.

Or make sure to send in a timely manner. Though the small delay tumbleweed noted would not be of any concern in most cases.

A read about RS-232 may help you clarify things.

Ioannis

Quote:

---

Originally Posted by Ioannis

Either one character or million of characters, the RS-232 sends each character alone. It has start bit, stop bit, maybe a parity bit too and the data itself. So, if between characters, there is small or big delay it should not matter, in most cases anyway.

You have to study carefully the modules you use if they need specific timings.

Some LORA modules I use seems to wait for a bit of time and if next character has not arrived in this time frame, sends the characters already in the buffer. Then the next characters are not lost but sent immediately after the previous transmission.

Now, what happens on the receiver side is the users responsibility to collect the data in good order.

Or make sure to send in a timely manner. Though the small delay tumbleweed noted would not be of any concern in most cases.

A read about RS-232 may help you clarify things.

Ioannis

---

It's just weird that I'm only transmitting at 9600 baud, and the same thing happens no matter how long the 1st string is. Only happens with that transceiver module, none of the other models from the same manufacturer have the issue. No joy in getting any response from the manufacturers either. Might try sending it through hardware perhaps.

Troy

Are you sure the settings of the internal registers are the same on all you modules?

Can you check/verify that?

Also, power supply should be capable to withstand the peak currents of the module. Should be able to supply clean 3.5A with no problem.

Have you added decoupling capacitors?

Ioannis

Quote:

---

Also, power supply should be capable to withstand the peak currents of the module. Should be able to supply clean 3.5A with no problem.

---

Okay, that's something that could be an issue. I normally run a 2W transceiver on this system and I remember checking battery and voltage reg to ensure capability there; but I have to fess, it's one thing I overlooked when switching up to a 5W module. Good call - thanks! Actually, good calls on all those points.

Cheers,

Troy

Ioannis, I owe a you a beer or 3 :) My voltage reg was underrated to that required 3.5A. I got away with it for the 2W modules, but not these. I never would've thought of that being the culprit for this issue, but, well, so far so good in testing with a beefier reg.

THANK YOU!

Troy

Glad you got it working!

Beer accepted!

Ioannis