Facebook
Google
GitHub
Linkedin
What specifically are you having trouble with? It is better to resolve problems individually than to keep pressing RESET. That just leads to introducing ever more and new problems in my experience.
Remote control by location (PIC in Oshonsoft)
- Thread starter camerart
- Start date
Hi JT,
I'm not having any specific trouble, other than not being good at programming.
I've been staring at the program for years, as it built up, I got used to the variables, now thanks to your welcome new program, I now have to get used to different variables. This will take me some time.
How I normally program, is not like a good programmer like you, but I have to guess to some point and see if it works. sometimes I succeed and sometimes not, as this time.
Have a look at what I come up with tomorrow, when I have another go, while getting used to the new variables.
Today, in SIM, the program I posted, filled the BUFFER ok, but didn't PARSE.
C.
Hi JT,
Success
I've updated the latset REMOTE program in #730
As I was working through my second run, of your posted program, I noticed some UPPERCASE and some lower case VARIABLES, this time I took more time, and after filling the page with MOSI (Which is the TX RX calrification), once noticed I changed them all to BORI, and it now works.
At the moment the test messages should look similar to this:
$BORI,11,22,33,W
OR
$GNRMC,123456.80,A,1234.77326,N,12345.94201,W,0.213,,140620,,,D*70
With of course number variations.
After I've rechecked it all, I'll delete the commented out stuff.
You added BST into the program title, would you prefer it was added?
C.
Success
I've updated the latset REMOTE program in #730
As I was working through my second run, of your posted program, I noticed some UPPERCASE and some lower case VARIABLES, this time I took more time, and after filling the page with MOSI (Which is the TX RX calrification), once noticed I changed them all to BORI, and it now works.
At the moment the test messages should look similar to this:
$BORI,11,22,33,W
OR
$GNRMC,123456.80,A,1234.77326,N,12345.94201,W,0.213,,140620,,,D*70
With of course number variations.
After I've rechecked it all, I'll delete the commented out stuff.
You added BST into the program title, would you prefer it was added?
C.
Hi JT,
Ok, good.
Next I've got to add a TEST only message to send to BASE.
then change the BASE program in a similar way only this time using $BIRO.
C.
Hi,
After re-gluing a couple of dry joints on the DATASWITCH, the REMOTE PCB is now working
There are a couple of gliches, but it is missing READings, but getting all of the DATA, albeit after a short delay. In other words, each of the messages have gaps.
Next to change the BASE program, so that each PCB is talking to each other, instead of my TEST Terminal messages.
C
After re-gluing a couple of dry joints on the DATASWITCH, the REMOTE PCB is now working
There are a couple of gliches, but it is missing READings, but getting all of the DATA, albeit after a short delay. In other words, each of the messages have gaps.
Next to change the BASE program, so that each PCB is talking to each other, instead of my TEST Terminal messages.
C
Hi,
I'm a bit stuck!
Using the TEST messages from a computer terminal, here's an example:
Both of the PCBs work independently, but when they are tested together sending messages between them, then they don't work.
Here are the two programs: Remember the REMOTE doesn't have a QEIDEG or JOYSTICKS input.
C
I'm a bit stuck!
Using the TEST messages from a computer terminal, here's an example:
Both of the PCBs work independently, but when they are tested together sending messages between them, then they don't work.
Here are the two programs: Remember the REMOTE doesn't have a QEIDEG or JOYSTICKS input.
C
Last edited:
What is it supposed to be doing?
There still is this:
Also, both ends are trying to send the $BORI message, is that correct?
There still is this:
It waits forever for a sentence. Is one always coming on the current channel? This loop is from the old test code where it had nothing else to do. You'll have to open it up so that it runs the other stuff while waiting for a message.
Also, both ends are trying to send the $BORI message, is that correct?
Hi JT,
I'll have to have a closer look tomorrow, to understand what you are saying.
______________________________________________________________________________________________
Also, both ends are trying to send the $BORI message, is that correct?
No, A message from the BASE to REMOTE is BORI (BASE OUT, REMOTE IN) and a message from REMOTE to BASE is BIRO (BASE IN, REMOTE OUT)
All relevent VARIABLES of each program reflect this.
e,g, In the BASE program, the VARIABLES look like this:
Dim prsed_BIRO As Bit 'parser found a REMOTE sentence and updated data
or
Const BIROguardSet = 50 '20ms * 50 = 1 sec to get a good REMOTE sentence
else
e,g, In the REMOTE program, the VARIABLES look like this:
Dim prsed_BORI As Bit 'parser found a BASE sentence and updated data
or
Const BORIguardSet = 50 '20ms * 50 = 1 sec to get a good BASE sentence
This will mix me up till I get used to it, this is why I used colours
EDIT: Slight spelling correction.
C.
Last edited:
Hi JT,
As the $BORI and $BIRO messages are 1x/LOOP. I'm wondering if they may be missed, as there not synchronised. (I think you mentioned this previously?)
If they need synchronising, it may be possible to sync them to the GPS, as each PCB has one, and they are pretty accurate with each other.
C
As the $BORI and $BIRO messages are 1x/LOOP. I'm wondering if they may be missed, as there not synchronised. (I think you mentioned this previously?)
If they need synchronising, it may be possible to sync them to the GPS, as each PCB has one, and they are pretty accurate with each other.
C
Hi JT,
To clarify.
If "open it up" means comment out (remove), then I'll try it. OK?
C.
To clarify.
If "open it up" means comment out (remove), then I'll try it. OK?
Code:
>>>>waitBuf:<<<< [Comment out?]
If buf_done = 1 Then 'If got A sentence, parse it
Goto do_parse
Endif
If ms05_RXguard = 0 Then 'If timeout, change channels
Gosub next_channel
Gosub setUARTchannel
Endif
'Other processing here
>>>>Goto waitBuf<<<< 'loop until something happensBy 'opening up' main I mean to collect all of the various functions in the loop and, as you note, not constrained by waiting on a sentence. That was left over from old stuff - always a danger when combing out the knots.
Keep in mind that the main loop should loop as fast as possible so it can't wait on things like receiving a sentence. That's what the buf_done flag is for. It checks that flag and proceeds with the rest of the tasks in the loop if the flag is not set.
With that in mind, it is not a good idea to type out the compass, air data and a test message on EVERY loop. That will slow processing down to the comms rate. You probably don't want that. The customary method to handle something like this is to separate the acquisition and the reporting of the data. Acquire the data as often as possible but schedule the reporting to some human-readable time frame. To that end, I added a timer, ms20_reporttimer, which schedules air data/compass reports at 200ms intervals. You can change it as necessary. Now the air data/compass gets read and processed as fast as possible (for use by the flyer) but the reporting doesn't hog the whole system.
I also added a similar scheduler (another timer) to control the $BIRO message transmission for the same reason. Check it out and see how main will run and update and look for $sentences much faster, leaving the loop only to process and then only on a schedule.
Finally, you might want to think about your air data and compass routines. Just reading (not reporting) the compass takes a whopping 99.4ms at 8MHz. Reading air data takes 25ms. That's a long time if you are going to do real-time flight control. Faster PIC clock, integer arithmetic, constant folding and simplification of calculations come to mind.
Anyway, the scheduling idea is something to consider. You really have to separate data acquisition, flight control etc. from the much slower serial output if you are going to have a shot at this working.
Have fun!
Keep in mind that the main loop should loop as fast as possible so it can't wait on things like receiving a sentence. That's what the buf_done flag is for. It checks that flag and proceeds with the rest of the tasks in the loop if the flag is not set.
With that in mind, it is not a good idea to type out the compass, air data and a test message on EVERY loop. That will slow processing down to the comms rate. You probably don't want that. The customary method to handle something like this is to separate the acquisition and the reporting of the data. Acquire the data as often as possible but schedule the reporting to some human-readable time frame. To that end, I added a timer, ms20_reporttimer, which schedules air data/compass reports at 200ms intervals. You can change it as necessary. Now the air data/compass gets read and processed as fast as possible (for use by the flyer) but the reporting doesn't hog the whole system.
I also added a similar scheduler (another timer) to control the $BIRO message transmission for the same reason. Check it out and see how main will run and update and look for $sentences much faster, leaving the loop only to process and then only on a schedule.
Finally, you might want to think about your air data and compass routines. Just reading (not reporting) the compass takes a whopping 99.4ms at 8MHz. Reading air data takes 25ms. That's a long time if you are going to do real-time flight control. Faster PIC clock, integer arithmetic, constant folding and simplification of calculations come to mind.
Anyway, the scheduling idea is something to consider. You really have to separate data acquisition, flight control etc. from the much slower serial output if you are going to have a shot at this working.
Have fun!
Hi JT,
Thanks for the modifications.
When I receive your programs, if I make changes, then I remove your intitials from the title, so I know it's one I've changed.
I found the COMPASS wasn't working due to being commented out, so it's now working, and made a few minor changes, including removing much of the commented out stuff. I've also changed some VARIABLES etc, e,g, changed REMVOLT to BASEVOLT, as we're working on the REMOTE PCB and the info now is coming from BASE.
I failed on the first attempt and had to return to GO. This is where mistakes are made so I'll keep checking.
EDIT: This REMOTE program is working ok.
Cheers, C.
Last edited:
Hi,
I'm now thinking about how to use this system!
One of the thoughts is, that the messages going between the PCBs are able to clash, so some will be missed, I'm not sure if this is much of an issue yet, but I've been looking into the GPS settings, and think both modules may be able to have a synchronised signal from one of the pins, which would time the SEND/RECEIVE messages.
Many of the messages are for me to test that each of the peripherals is working, so perhaps some can be switched off. (Perhaps they could be engaged using a transmitter switch?) e,g, once the Transmitter location has been set, then as long as it doesn't move, then the location can be switched off. (If the GPS time is needed for sync, then it can't be switched off)
EDIT: I've delved deeper into the GPS modules, and from what I understand, the type used here, sync to accurate Satellite clocks, but aren't in sync with one another, so the square waves of the 2x output pins, stay the same, but one may be fixed a little time after the other. I'm sure if needed, this could be used to sync TX/RX.
EDIT: I now think that within nS, the GPS modules are in sync.
C.
I'm now thinking about how to use this system!
One of the thoughts is, that the messages going between the PCBs are able to clash, so some will be missed, I'm not sure if this is much of an issue yet, but I've been looking into the GPS settings, and think both modules may be able to have a synchronised signal from one of the pins, which would time the SEND/RECEIVE messages.
Many of the messages are for me to test that each of the peripherals is working, so perhaps some can be switched off. (Perhaps they could be engaged using a transmitter switch?) e,g, once the Transmitter location has been set, then as long as it doesn't move, then the location can be switched off. (If the GPS time is needed for sync, then it can't be switched off)
EDIT: I've delved deeper into the GPS modules, and from what I understand, the type used here, sync to accurate Satellite clocks, but aren't in sync with one another, so the square waves of the 2x output pins, stay the same, but one may be fixed a little time after the other. I'm sure if needed, this could be used to sync TX/RX.
EDIT: I now think that within nS, the GPS modules are in sync.
C.
Last edited:
Hi,
As the Tranmsitter and Receiver are working, with maybe a couple odd faults, that I can look into, I've now got to work out how to convert the transmitter Joystick etc movements into Receiver motor etc controls. I've joind a couple of Radio control forums, that may be more suitable than electronics forums, but I will start a separate post here in case.
C.
As the Tranmsitter and Receiver are working, with maybe a couple odd faults, that I can look into, I've now got to work out how to convert the transmitter Joystick etc movements into Receiver motor etc controls. I've joind a couple of Radio control forums, that may be more suitable than electronics forums, but I will start a separate post here in case.
C.
Hi,
I've been on ETO, as they were helping me previously with MAGMASTER.
I now have 3x programs, the Self test, and averaging for Magmaster (Compass calibration), a transmitter (BASE) and a mobile (REMOTE). All appear to be working.
Next is quite different! I/we will start adding the CONTROL to the programs.
ALT uses the Barometers.
On the ground, at initialisation, both will READ the same.
Moving the Throttle stick FORWARD will tell the REMOTE to go HIGHER than it is, and Visa versa.
DIRECTION of AIM.
I'm not sure yet, whether this will be calculated, or use the BASE DIR knob.
LAT LONG. I think at first, the field of view should be as a matrix as LAT LON on a map.
Move the LAT stick to the RIGHT and the REMOTE moves RIGHT, and visa versa, similar for LON.
There should be a readout, say ALT MTRs. LAT LON MTRS and DIRECTION, which if calculated will need to be sent back.
The REMOTE only needs to send back battery voltage and necessary telemetry, as we know where it should be, even if it loses signal.
Here is the Selft test/Magmaster program:
C.
I've been on ETO, as they were helping me previously with MAGMASTER.
I now have 3x programs, the Self test, and averaging for Magmaster (Compass calibration), a transmitter (BASE) and a mobile (REMOTE). All appear to be working.
Next is quite different! I/we will start adding the CONTROL to the programs.
ALT uses the Barometers.
On the ground, at initialisation, both will READ the same.
Moving the Throttle stick FORWARD will tell the REMOTE to go HIGHER than it is, and Visa versa.
DIRECTION of AIM.
I'm not sure yet, whether this will be calculated, or use the BASE DIR knob.
LAT LONG. I think at first, the field of view should be as a matrix as LAT LON on a map.
Move the LAT stick to the RIGHT and the REMOTE moves RIGHT, and visa versa, similar for LON.
There should be a readout, say ALT MTRs. LAT LON MTRS and DIRECTION, which if calculated will need to be sent back.
The REMOTE only needs to send back battery voltage and necessary telemetry, as we know where it should be, even if it loses signal.
Here is the Selft test/Magmaster program:
C.
Hi,
I dug out a baby tricopter for testing on, and with props off tried controlling it with a conventional transmitter. The Tcopter has a KK2 board which needs arming first, this is done with the RUDDER stick.
Then I looked at a previous view of the Transmitter signal on an Oscilloscope, to get the idea of how the PWM is transmitted each CH is in sequence. CH4 is RUDDER, so CH4 PWM needs to go LOW to arm the KK2.
This is now the first job.
C
I dug out a baby tricopter for testing on, and with props off tried controlling it with a conventional transmitter. The Tcopter has a KK2 board which needs arming first, this is done with the RUDDER stick.
Then I looked at a previous view of the Transmitter signal on an Oscilloscope, to get the idea of how the PWM is transmitted each CH is in sequence. CH4 is RUDDER, so CH4 PWM needs to go LOW to arm the KK2.
This is now the first job.
C
