Serout2 question

[Ioannis]

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

[rocket_troy]

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

[Ioannis]

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

$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

$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

[tumbleweed]

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.

[rocket_troy]

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

[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

[rocket_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

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