Hi,
I have 2x PICs on PCBs (BASE REMOTE) 'talking' to each other via simplex radio link. (HC-12)
On each PCB is a GPS with timing.

I want the PCBs to send messages to each other, in turn, and I'm not sure of the best way to do this.

I can imagine the GPSs controlling each PIC so they alternate, or the BASE sends a message which once received by the REMOTE, it is then triggered to send the return message.

Any suggestions, please?
Camerart

 

Can you define how the messages will be exchanged?
Is one device a master and the other a slave?
Do they exchange information continually or is there a delay between messages?

 

Can you define how the messages will be exchanged?
Is one device a master and the other a slave?
Do they exchange information continually or is there a delay between messages?

Hi K,
As there is MASTER and SLAVE between the 2xPICs on each PCB, I use BASE and REMOTE (Remote control)
Both BASE and REMOTE send messages as they feel at the moment, which of course block each other. I think they need to toggle between them.
The image shows both sets of messages, but I had to switch each ON and OFF in turn, and runs for app 3 seconds.
C.

 

Given the HC-12 is half-duplex - you can't transmit and receive simultaneously you have no choice but to implement some form of master-slave relationship; BASE transmits to REMOTE, REMOTE acknowledges and sends its own data if a message is queued, BASE acknowledges. If BASE has no message it sends a NOMESSAGE token so the REMOTE can still respond with its own message. A lot depends on the criticality of message timing. Keep messages short and use more of them.

Another option is TDM - time division multiplexing. Usually used with a MASTER and several SLAVES, after receiving a SYNC message from the MASTER, each SLAVE waits a known length of time determined by its node # then transmits its message or a NOMESSAGE placeholder. after all have transmitted the MASTER sends its own message followed by SYNC.

Given you have a GPS you have a guaranteed timing you could simply implement a form of TDM where BASE and REMOTE transmit on defined time slots. Say your messages are 100bytes at 115200bps and 11bits/byte = 9.5mS approx message transmit time. So you could arrange for BASE and REMOTE to transmit on alternate 10 or 15mS 'slots'.

 

Given the HC-12 is half-duplex - you can't transmit and receive simultaneously you have no choice but to implement some form of master-slave relationship; BASE transmits to REMOTE, REMOTE acknowledges and sends its own data if a message is queued, BASE acknowledges. If BASE has no message it sends a NOMESSAGE token so the REMOTE can still respond with its own message. A lot depends on the criticality of message timing. Keep messages short and use more of them.

Another option is TDM - time division multiplexing. Usually used with a MASTER and several SLAVES, after receiving a SYNC message from the MASTER, each SLAVE waits a known length of time determined by its node # then transmits its message or a NOMESSAGE placeholder. after all have transmitted the MASTER sends its own message followed by SYNC.

Given you have a GPS you have a guaranteed timing you could simply implement a form of TDM where BASE and REMOTE transmit on defined time slots. Say your messages are 100bytes at 115200bps and 11bits/byte = 9.5mS approx message transmit time. So you could arrange for BASE and REMOTE to transmit on alternate 10 or 15mS 'slots'.

Hi I,
A lot to think about there!
1/GPS timing: From results during this project, I doubt GPS timing will work, so I'll leave it till later.

2/ TDM: It's dawned on me that most of the messages, are for me to monitor what's going on, so nearly all of the ones from the REMOTE won't be needed (See below).
Looking at the image, there are 2x with $ at the front. These are the control messages, that could easily toggle in turn, (I think?) while I monitor, the BASE messages only.

I'm also wondering if the monitor messages could be all combined in one into 1x long message each.
P.S. I'll start another thread about GPS timing.
C.

 

Was there meant to be an attachment on your last message?

It seems to me, looking at the image of your transmissions (joystick to drone perhaps?) that the simplest option would be for BASE to send regular messages and REMOTE responds OK or OK and here's mine but with no acknowledgement back to REMOTE.

Slightly more robust, BASE sends a message #XXX and REMOTE responds OK #YYY where YYY is last one received so BASE knows that if XXX = YYY REMOTE got it, else resend. Similarly if REMOTE sends a message # eg #AAA and BASE adds the last REMOTE message #BBB in its transmission then REMOTE can decide, if AAA != BBB, whether to resend an earlier message as well as the new one. Its a form of windowing algorithm. Depends on how critical the messages are and timing.

 

Was there meant to be an attachment on your last message?

It seems to me, looking at the image of your transmissions (joystick to drone perhaps?) that the simplest option would be for BASE to send regular messages and REMOTE responds OK or OK and here's mine but with no acknowledgement back to REMOTE.

Slightly more robust, BASE sends a message #XXX and REMOTE responds OK #YYY where YYY is last one received so BASE knows that if XXX = YYY REMOTE got it, else resend. Similarly if REMOTE sends a message # eg #AAA and BASE adds the last REMOTE message #BBB in its transmission then REMOTE can decide, if AAA != BBB, whether to resend an earlier message as well as the new one. Its a form of windowing algorithm. Depends on how critical the messages are and timing.

Hi I,
No attachment.

The peripherals: Compass, GPS, etc all begin with where they are being READ from [ BASEXXXx] and the $ to W are the BASE, REMOTE control messages.

While concentrating in this area of the project, I've now remembered that on each unit, there is a facility for a screen. Previously we had a Nokia one, but it was unreliable due to Zebra strips, so went into the 'later' pile. If we used a screen at each end, then only the $ to W messages need to be exchanged.
BASE to REMOTE must be as fast as possible, but REMOTE to BASE is less urgent so REMOTE could count BASE messages till 'say' it received '5' then send one back.

If this sounds ok, we can go in that direction.
C

 

A master/slave setup is reliable and easy to code. Just don't let the slave devices "talk" until they are asked to.

Depending upon the reliability of the radio link you might allow the slave to re-transmit a packet if an acknowledgement of a successful transmission is not sent back within a given timeframe, the timeframe for re-transmitting the packet must also be limited so that the master won't try to "talk over" the slave's re-transmission.

Another good idea is for any transmitting device to wait for the receiver on the other end to recover from its transmission state before replying.

 

A master/slave setup is reliable and easy to code. Just don't let the slave devices "talk" until they are asked to.

Depending upon the reliability of the radio link you might allow the slave to re-transmit a packet if an acknowledgement of a successful transmission is not sent back within a given timeframe, the timeframe for re-transmitting the packet must also be limited so that the master won't try to "talk over" the slave's re-transmission.

Another good idea is for any transmitting device to wait for the receiver on the other end to recover from its transmission state before replying.

Hi D,
I think there are BITs in the CODE where your suggestion would fit in, telling each end 'don't send till asked'.
Thanks.
C

 

Hi C,
Ref the TFT.bas for some reason it will not allow the txt to be added to the Conversation, so we will try it this way, hopefully.
Is it this version you are requesting.??

E

 

Hi C,
Ref the TFT.bas for some reason it will not allow the txt to be added to the Conversation, so we will try it this way, hopefully.
Is it this version you are requesting.??

E

Morning E,
I don't remember it, but it looks good, and compiles ok, with INCLUDE FONT1.
Can you let me know which screens this works with, then I'll order some, or will it work with any SPI TFT screen?
These are a better size than the 5110 type, but after digging them out, find them fine for testing, and other uses.
Thanks.
C.

 

Hi C,
Ref the TFT.bas for some reason it will not allow the txt to be added to the Conversation, so we will try it this way, hopefully.
Is it this version you are requesting.??

E

Hi E,
Regarding not allowing: I think a BAS file has to be copied and pasted into TXT, before sending.
C

 

Hi,
I have a program with the 5110 screen CODE that works.
I have a FULL program with all peripherals etc.

While integrating the sections of 6110 CODE into the FULL program, I got this error:
It opens the INCLUDE 'fontsml' which is the BMP DIGIT stored file.
When looking for line 1989 as shown, there isn't a line 1989?

This doesn't happen on the simple 5110 program.
Any clues please?
NOTE: The FULL program is too large to post.

EDIT: I used different folders for the FULL prgram and the 5110 one. They have INCLUDES and I think this may have been the problem, as I now have them both in the same folder and the error has gone.
C

 

Hi,
I figured out what I think the problem is! The 5110 screen CODE was written using Oshonsoft SW, where I'm trying to integrate it into a SPI using HW program.
I've started a new thread as it is a different subject: https://forum.allaboutcircuits.com/...-5110-sw-code-to-hw-code-in-oshonsoft.188053/
Cheers, C