Help Please: PICAXE and Robot Boat

Robin Lovelock

Senior Member
Thanks Martin. Space on bytes was getting tight (see those commented out power test lines near start) but the 08M limitation was lack of variables. I could have tried Hippy's PEEK/POKE idea, but dropping the third servo made more sense. We may not even need a second servo.
Robin
www.gpss.co.uk/autop.htm
 

hippy

Technical Support
Staff member
I presume you will also be re-visting the code once you've done further testing, taken all components to a later milestone, and there will be an opportunity to rewrite the code for 'Cross-Atlantic use'.

At that point you will better know what the PICAXE has to do and can re-design for that and to cater for loss of power, resets and such like it may encounter at sea, while optimising to consume minimum power. For example, there's no need to run at 8MHz when it's not expecting any serial.

This is all 'typical design cycle' stuff so nothing wrong there; have a vague idea of what's needed, write code to prove the concept, tweak it until it works, end up with a rather convoluted mess, write a proper specification based on what the code does, rewrite the code to better fit the specification.

One potentially interesting side-project ( probably of interest to others doing autonomous vehicles ), is how to minimise the servo PULSOUT loop consumption. There's scope there for dynamically reducing PICAXE clock speed to a minimum while still maintaining loop time and servo pulse accuracy. Possibly even using NAP in place of part of the PAUSE.

Code:
w1 = 320
w2 = 320
w3 = 320

Do
  Gosub ServoLoop
Loop

ServoLoop:

  w0 = 4000 - OVERHEAD_TIME - w1 - w2 - w3 / 20

  div8MHz = 1

  Do
    if ( w1 & 1 ) <> 0 Then Optimised
    if ( w2 & 1 ) <> 0 Then Optimised
    if ( w3 & 1 ) <> 0 Then Optimised
    w0 = w0 / 2
    w1 = w1 / 2
    w2 = w2 / 2
    w3 = w3 / 2
    div8MHz = div8MHz * 2
  Loop Until div8MHz = 32

Optimised:
  Select Case div8MHz
    Case 1  : SetFreq M8
    Case 2  : SetFreq M4
    Case 4  : SetFreq M2
    Case 8  : SetFreq M1
    Case 16 : SetFreq K500
    Case 32 : SetFreq K250
  End Select

  Pause w0
  PulsOut 1, w1
  PulsOut 2, w2
  PulsOut 3, w3

  Return
 

Robin Lovelock

Senior Member
Thanks Hippy - all useful grist to the mill. I would be surprised if that program does not get revisited, but any re-write will be followed by many weeks or months of 24/7 tests, even if the boat system(s) does not leave my back yard. Very much like our bottle tracking project years ago. But the picaxe part is a very small fraction of the overall system, and other more complex parts, including the boat itself, cannot be neglected. These other parts are more likely to fail - especially if not tested thoroughly. I've added a link to this Forum thread from my page below, and also mentioned this recent picaxe stuff within the Microtransat community. Many Thanks for your help.
Robin
www.gpss.co.uk/autop.htm
 

Robin Lovelock

Senior Member
First a simple question for Hippy:
What is the simple algebraic meaning of this line ?
w0 = b13 Min MIN_INPUT Max MAX_INPUT - MIN_INPUT * GAP_SERVO / GAP_INPUT + MIN_SERVO
If it helps, the comment after says:
'w0 = b13 * 91 / 126 + 100 'scale servo position 100 to 191

I'm sorry asking this question so late, but the program has been working fine, and I've just needed to look closely at this statement - I'll explain that in a moment. When I looked at it, I realized I did not understand it - those extra Min and Max statements. I was expecting something more like the following comment.

Sorry again for asking this now.

Now the fuller explanation, just in case you see something fundamentally wrong in my approach to the latest changes in the program below.

As you may recall, v1f of the program does what I wanted: control two servos from the RS232 line from the iPAQ, and also a reed relay power switch, used to power on and off the GPS and iPAQ, giving a less power hungry and more reliable robot boat nav system.

The latest idea I want to experiment with is using that 2nd unused servo, to operate the power button on the iPAQ. So instead of the reed relay being used to switch off both iPAQ and GPS, it only switches off the GPS. Toggling the 2nd servo to operate the iPAQ power button, saves the 30 seconds or more needed to reboot the iPAQ Windows Mobile operating system. Yes, I've looked at the more elegant solutions, but am reduced to a relay "mechanical" switch.

The changes I am experimenting with involve using the existing counters in the picaxe program and setting the w2 servo pulse time to one value or the other, based on the counter values. I did not understand that line at the top of this posting, so I'm trying w2 values of 100 and 200. My counter logic may not be correct because I'm not seeing the 2nd servo move - after the test pattern at the very start.

You will notice that I'm shaving statements away at the very start, to fit the bigger program into available 08M memory :)

Many Thanks in advance - even if you only have time to explain that one line at the start.

Robin
www.gpss.co.uk/autop.htm



Code:
'SC1.BAS servo controller for robot boat
'v1g 12 Sep 2009 (c) Robin Lovelock www.gpss.co.uk/autop.htm 
' - with a great deal of help from HIPPY on Picaxeforum.co.uk :-)
'input is serial RS232 input group of 3 bytes: 
'127=sync, 0,1 or 2=servo number, 0 to 126 servo position
'the input servo position from RS232 is 0 to 126, 64=centre
'position sent to servo system is 100 to 191, 146=centre

'switching between 4MHz and 8MHz was done to program
'around the restriction in the PICAXE system that
'SERVO/SERVOPOS only works at 4MHz whereas
'SERIN at 4800 baud only works at 8MHz
'The use of IF PIN3 THEN allows the switch
'to 8MHz to be brief, allowing the servos to be held
'in position rather than allowed to go limp.
'However use of IF PIN3 causes occasional twitching
'of servos for an unkown reason.- maybe in the PICAXE system.
'We programmed around this in a later version
'since unwanted twitching of servos may decrease their life.

'Version 1d and later did not need to switch speed or use IF PIN3 
'because it uses PULSOUT instead of SERVO/SERVOPOS
'However, SERVO/SERVOPOS are used at the start for the test pattern.

'Version 1e and later uses Pin0 as a timed switch
'to permit the computer to switch off power for a time
'for this the instruction is sync,9,time in minutes
'e.g. 127,9,15 = switch off for 15 minutes
'v1f drops support for third servo so can use w3 for power timer
'so that power on is limited to power off + 2 minutes
'This means the picaxe card also acts as an iPAQ watchdog timer
'v1g toggles the 2nd servo to switch on or off the iPAQ.


 #Picaxe 08M
 SETFREQ M4 'standard 4MHz
  
 SERVO 1,146: SERVO 2,146 '1f :  SERVO 4,146 'middle positions
 'test pattern: fully clockwise, middle, anti-clockwise.
 for b0 = 0 to 126 step 63 
   b13 = b0 * 91 / 126 + 100
   b1=b13: b2=b13: b3=b13
   SERVOPOS 1, b1 'move servo 0
   PAUSE 1000
   SERVOPOS 2, b2 'move servo 1
   PAUSE 1000
   '1f SERVOPOS 4, b3 'move servo 2
   PAUSE 2000
 next b0
 
 'test PIN 0 power switch ON for 4 secs
 'HIGH 0
 'PAUSE 4000
 'LOW 0
 'PAUSE 1000
 
 'remember servo positions and start at centre positions.
 '1g b1 = 146 : SERVOPOS 1, b1
 'b2 = 146 : SERVOPOS 2, b2
 'b3 = 146 : SERVOPOS 4, b3
 'PAUSE 3000 'allow servos time to travel
 Low 1 : Low 2 : Low 4 'switch off SERVO background
 
 
'this is the code from Hippy - with recent changes
SETFREQ M8 '8 MHz so SERIN will work
Symbol MIN_INPUT = 0
Symbol MAX_INPUT = 126
Symbol GAP_INPUT = MAX_INPUT - MIN_INPUT

Symbol MIN_SERVO = 200
Symbol MAX_SERVO = 400
Symbol GAP_SERVO = MAX_SERVO - MIN_SERVO

w1 = 320 ' 160 @ 4MHz
w2 = 320 ' 160 @ 4MHz
'1f w3 = 320 ' 160 @ 4MHz
w4 = 0  '1e power switch timer. Start ON.
w3 = 9000 'power off 3 minutes after on

HIGH 0 'start with power ON
'w0 = 4000 - w1 - w2 - w3 / 100
w0 = 4000 - w1 - w2 / 100


SetInt %01000, %01000

Do
  Pause      w0
  Pulsout 1, w1 
  Pulsout 2, w2 
  'Pulsout 4, w3
  If w4 = 0 Then 'pin0 used as power switch
    HIGH 0 'switch ON
    If w5 > 0 Then
      w5 = w5 - 1
      If w5 = 0 Then
        SetInt %01000, %01000
      End If
    End If
  Else
    w4 = w4 - 1 'count down before above switch ON
    if w4 = 0 then
      w3 = 6000 'power off 2 minutes after on
    end if
    if w4 < 100 then '1g toggle servo switch 2 secs
      w2 = 200
    else
      w2 = 100
    endif
  End If
  if w3 = 0 then
    w4 = 3000 'switch on to try again in 1 minute
    w5 = 3000 ' w5 = 1 * 60 * 1000 / 20 
    w3 = w4 + 6000 'power off 2 minutes after on
    LOW 0
  else
    w3 = w3 -1
    if w3 < 100 then '1g toggle servo switch 2 secs
      w2 = 200
    else
      w2 = 100
    endif
  endif
Loop

Interrupt:
  if w5 > 0 then 'if interrupts still disabled
    Return
  end if
  SERIN 3, N4800_8, (127), b12, b13
  if b12 < 9 then 'not for 127,9,1
    w0 = b13 Min MIN_INPUT Max MAX_INPUT - MIN_INPUT * GAP_SERVO / GAP_INPUT + MIN_SERVO
    'w0 = b13 * 91 / 126 + 100 'scale servo position 100 to 191
  end if
  Select case b12
    Case 0 : w1 = w0 'vane rudder
    Case 3 : w2 = w0 '1d Wing-Sail was Case 1
    '1f Case 2 : w3 = w0 'or sail winch
    Case 9 : w4 = b13 * 3000 ' w4 = b13 * 60 * 1000 / 20
             LOW 0 'switch OFF and start timer to switch back ON.
             w5 = 3000 ' w5 = 1 * 60 * 1000 / 20 
             w3 = w4 + 6000 'power off 2 minutes after on
             Return ' Return with interrupt disabled               
  End Select
  'w0 = 4000 - w1 - w2 - w3 / 100
  w0 = 4000 - w1 - w2 / 100
  Pause w0
  SetInt %01000, %01000
  Return
 

hippy

Technical Support
Staff member
w0 = b13 Min MIN_INPUT Max MAX_INPUT - MIN_INPUT * GAP_SERVO / GAP_INPUT + MIN_SERVO

Scales a servo setting as specified in b13, which will range in value between MIN_INPUT and MAX_INPUT, to a value which will move an actual servo between the positions indicated by MIN_SERVO and MAX_SERVO.

It's the algebraic equivalent of the straight-line graph which has 'b13' required value on one axis and servo output on the other, which passes through two points ( MIN_INPUT, MIN_SERVO ) and ( MAX_INPUT, MAX_SERVO ).

The "Min" and "Max" operators are there to force the input values to be in range, so if servo position were the vertical axis you'd have a graph which looked like ...
Code:
  |
S |      _____
e |     /
r |____/
v |
o |___________
    b13 value
To adjust, set MIN_SERVO and MAX_SERVO to values which give end-to-end travel of your servo, then adjust MIN_INPUT and MAX_INPUT for the two values of 'b13' being used which will indicate those positions.

Not sure I'd want to go to a servo operated switch. A better alternative would be to bring flying wires from the switch contacts out of the iPAQ and have relay contacts effect a closure of the switch.
 

Robin Lovelock

Senior Member
Many Thanks Hippy. I'm never too young to learn :)
I guess my w2 values are OK, but I need to check the logic again.

You are right of course, about that not being a good solution: it's plan C in:
Plan A: find VB.Net statement under Windows Mobile that can do Full Windows ability for a task to SUSPEND (Power off) the iPAQ for a specified number of seconds. This is the neat solution, but intensive googling only seems to reveal it's not yet possible.
Plan B: wire into the iPAQ, and get at the power switch contacts. I looked inside the iPAQ and such an approach seems to be a nightmare.
Plan C: a servo or solonoid pressing the switch mechanically.

Robin
www.gpss.co.uk/autop.htm
 

Robin Lovelock

Senior Member
Good Morning Gentlemen, and Hippy of course :)

You will be pleased to know my latest question is simple, but I will start with the explanation: I've decided to add a second picaxe card to both simplify and improve my power-saving control logic. I'm keeping the originial 08M card for servo control and the reed relay switch, used to power off the GPS for the required period. I'm also sticking to version 1f of the SC1.BAS program which seems to work reliably.

The second picaxe is used to operate that nasty relay that presses on the iPAQ to switch it ON. The improvement relates to the fact that I intend the previously unused RS232 input on the second picaxe to be used to monitor the GPS and switch the iPAQ on when the GPS is tracking - maybe a minute after the other picaxe switches it on. This way, the iPAQ can be switched on for the minimum period of time. I'm hoping to use the Windows Mobile OS to switch the iPAQ off, after 1 minute, but I may also include this (eventually) in the second picaxe program SC2.BAS below.

And now my simple question: the program below seems to work, but I need a bit more knowledge about that SERIN statement I'm using. I don't need to use any of the incoming GPS data - just wait on the required text appearing.

SERIN 3, N4800_8, (",A,"), b12

LOTS of text data comes out of the GPS, typically starting with text such as $GPGLL or $GPRMC and quite a few other message types. One particular one, $GPRMC includes ",V," when the GPS is not yet ready, and ",A," when it is tracking. So my SERIN line is simply looking for ",A,"

The whole system seems to work - almost. I'm still using my finger to press the iPAQ switch when the switch servo waggles. But I think I've seen it "switch on" when the GPS is not ready. It could be that SOMEWHERE in all those other GPS messages, there is another ",A," somewhere. OR maybe, the SERIN statement returns before it has seen the ",A," because of something like buffer overflow in the low level picaxe software.

You can see that my SERIN is only asking for one byte. It's trying to read and ignore ALL the bytes coming past, until it sees ",A,".

So I'm guessing, either I need to change this statement, or maybe make my logic a little more complicated by looking for ",A," after "$GPRMC" but not after other message types.

Robin
www.gpss.co.uk/autop.htm

Code:
'SC2.BAS iPAQ switch for robot boat
'v1a 13 Sep 2009 (c) Robin Lovelock www.gpss.co.uk/autop.htm 
' see www.Picaxeforum.co.uk
'input is serial RS232 GPS data - to see when GPS is ready
'the GPS outputs text strings and includes ",A," when ready
'output is servo controlling switching of iPAQ power ON


 #Picaxe 08M
 SETFREQ M4 'standard 4MHz
  
 SERVO 1,91: SERVO 2,91:  SERVO 4,91 'low positions
 PAUSE 4000

 SETFREQ M8 '8MHz for SERIN 
 'wait until the GPS is ready
 SERIN 3, N4800_8, (",A,"), b12
 SETFREQ M4 'standard 4MHz
 PAUSE 1000
 
 SERVOPOS 1,126 'toggle servo to switch on iPAQ power
 PAUSE 1000
 SERVOPOS 1,91
 PAUSE 3000 'give servo time to travel then exit
 

eclectic

Moderator
http://www.gpsinformation.org/dale/nmea.htm

One of many sites with GPS information.

The “,A,” occurs in several different sentence types.

Here's a sledgehammer approach to play with:

Code:
;Forum 130909
;http://www.picaxeforum.co.uk/showthread.php?p=111867#post111867
#picaxe 08M
setfreq m8

main:

serin  1,t4800_8,("$GPRMC,"),b0,b0,b0,b0,b0,b0,b0,b0,b0,b0,b0,b1,b2,b3,b4,b5,b6
 ;"overwrites" the first 11 time bytes
 ;just b1 is needed for "A"
 
sertxd (b1,b2,b3,b4,b5,b6, cr,lf ) ; just for testing
if b1 = "A" then sertxd ("Correct",cr,lf)
endif
; then do other things

pause 2000 ; for testing only

goto main

#rem shortened version

#picaxe 08M
setfreq m8
main:

serin  1,t4800_8,("$GPRMC,"),b0,b0,b0,b0,b0,b0,b0,b0,b0,b0,b0,b1
 ;"overwrites" the first 11 time bytes
  
if b1 = "A" then sertxd ("Correct",cr,lf)
endif
; then do other things

goto main
e
 

Attachments

Robin Lovelock

Senior Member
Many Thanks Eclectic. You do yourself a diservice when you say "sledgehammer": that's a very neat solution. I must confess I've skipped the test code and gone straight to the heart of your solution, testing with my real hardware - which I still need to examine.

My latest version is below, and the important lines are the comment:
'e.g. $GPRMC,114801.000,A,5129.8944,N,00041.0771,W,3.53,358.23,280608,,*18
-based on data from the actual GPS used on Bray Lake. I thought that would be prudent, since over the years I've seen differences in things like the number of decimal places (if any) in the time field before that ,A,.

If I understand it correct, you've got it right first time, with :
serin 1,t4800_8,("$GPRMC,"),b0,b0,b0,b0,b0,b0,b0,b0,b0,b0,b0,b1

i.e. look for the "$GPRMC," then skip 11 bytes, then read b1 which should be A. I hope I've understood it correct. If not, that will explain why it does not yet seem to work :) But as I say, I need to check my hardware details again.

As you see below, if the byte is not an "A", I simply go back to the SERIN.

Many Thanks again
Robin
www.gpss.co.uk/autop.htm

Code:
'SC2.BAS iPAQ switch for robot boat
'v1a 13 Sep 2009 (c) Robin Lovelock www.gpss.co.uk/autop.htm 
' see www.Picaxeforum.co.uk
'input is serial RS232 GPS data - to see when GPS is ready
'the GPS outputs text strings and includes ",A," after $GPRMC when ready
'e.g. $GPRMC,114801.000,A,5129.8944,N,00041.0771,W,3.53,358.23,280608,,*18
'output is servo controlling switching of iPAQ power ON


 #Picaxe 08M
 SETFREQ M4 'standard 4MHz
  
 SERVO 1,91: SERVO 2,91:  SERVO 4,91 'low positions
 PAUSE 4000

 SETFREQ M8 '8MHz for SERIN 
 'wait until the GPS is ready
 waitgps:
 serin  1,t4800_8,("$GPRMC,"),b0,b0,b0,b0,b0,b0,b0,b0,b0,b0,b0,b1
 if b1 <>"A" then goto waitgps 'above from eclectic on picaxe forum
 'SERIN 3, N4800_8, (",A,"), b12 'original attempt from Robin
 SETFREQ M4 'standard 4MHz
 PAUSE 1000
 
 SERVOPOS 1,126 'toggle servo to switch on iPAQ power
 PAUSE 1000
 SERVOPOS 1,91
 PAUSE 3000 'give servo time to travel then exit
P.S. don't know why that posting shows a space between b and 0 :)
 
Last edited:

hippy

Technical Support
Staff member
maybe make my logic a little more complicated by looking for ",A," after "$GPRMC" but not after other message types.
If you're not interested in the actual data you can simply use ...

SerIn 3, N4800_8, ( "$GPRMC" )
SerIn 3, N4800_8, ( ",A," )
 

Robin Lovelock

Senior Member
I can see the risk of three of us replying at the same time here: Anyway - here goes :)

Thanks Hippy but, assuming Eclectic is right, and ,A, could occur in a different message, what you describe might find a later ,A,.

But main reason for this posting from me is that I followed the link to that NMEA site, to look for these other messages, and the first one I looked at was:
$GPRMC,123519,A,4807.038,N,01131.000,E,022.4,084.4,230394,003.1,W*6A

It's a good thing I was "prudent" and used the example from my actual GPS - which has an extra few characters of decimal seconds. So I reckon Eclectic will be telling me how I've misunderstood the statement - but it does not look like the obvious thing.

Waiting in anticipation :)
 

Robin Lovelock

Senior Member
Just to say that I saw and corrected the simple error of not reading from pin3 so now reads:
waitgps:
SERIN 3,t4800_8,("$GPRMC,"),b0,b0,b0,b0,b0,b0,b0,b0,b0,b0,b0,b1
if b1 <>"A" then goto waitgps 'above from eclectic on picaxe forum
'SERIN 3, N4800_8, (",A,"), b12 'original attempt from Robin
- but with same symptom of it not seeing an "A".

Looking forward to hearing if my earlier posting had correct interpretation of what this SERIN line should do with:
$GPRMC,114801.000,A,5129.8944,N,00041.0771,W,3.53, 358.23,280608,,*18

Robin
www.gpss.co.uk/autop.htm
 

Robin Lovelock

Senior Member
Also, I've just tried:
SERIN 3,N4800_8,("$GPRMC,"),b0,b0,b0,b0,b0,b0,b0,b0,b0,b0,b0,b1
if b1 <>"A" then goto waitgps 'above from eclectic on picaxe forum
'SERIN 3, N4800_8, (",A,"), b12 'original attempt from Robin

-instead of the T4800. Current version of SC2 is below.
I get a few servo twitches early on, but not the waggle intended.

Looking forward to hearing explanation of what:
SERIN 3,N4800_8,("$GPRMC,"),b0,b0,b0,b0,b0,b0,b0,b0,b0,b0,b0,b1
or the original
SERIN 1,T4800_8,("$GPRMC,"),b0,b0,b0,b0,b0,b0,b0,b0,b0,b0,b0,b1
were intended to do, if not what I said earlier.

i.e. look for the "$GPRMC," then skip 11 bytes, then read b1 which should be A.

Robin
www.gpss.co.uk/autop.htm

Code:
'SC2.BAS iPAQ switch for robot boat
'v1a 13 Sep 2009 (c) Robin Lovelock www.gpss.co.uk/autop.htm 
' see www.Picaxeforum.co.uk
'input is serial RS232 GPS data - to see when GPS is ready
'the GPS outputs text strings and includes ",A," after $GPRMC when ready
'e.g. $GPRMC,114801.000,A,5129.8944,N,00041.0771,W,3.53,358.23,280608,,*18
'output is servo controlling switching of iPAQ power ON


 #Picaxe 08M
 SETFREQ M4 'standard 4MHz
  
 SERVO 1,91: SERVO 2,91:  SERVO 4,91 'low positions
 PAUSE 4000

 SETFREQ M8 '8MHz for SERIN 
 'wait until the GPS is ready
 waitgps:
 SERIN 3,N4800_8,("$GPRMC,"),b0,b0,b0,b0,b0,b0,b0,b0,b0,b0,b0,b1
 if b1 <>"A" then goto waitgps 'above from eclectic on picaxe forum
 'SERIN 3, N4800_8, (",A,"), b12 'original attempt from Robin
 SETFREQ M4 'standard 4MHz
 PAUSE 1000
 
 SERVOPOS 1,126 'toggle servo to switch on iPAQ power
 PAUSE 1000
 SERVOPOS 1,91
 PAUSE 3000 'give servo time to travel then exit
 

Robin Lovelock

Senior Member
Just to say that I'm beginining to wonder if the low level picaxe software, looking for the string, might miss a few bytes that follow. But this is where I need to hear from Eclectic why he read that particular number of bytes, before the required one that should be "A". I'm assuming he was looking at the NMEA spec that has less bytes before it. That's why I was amazed he seemed to be skipping exactly the correct number of bytes for my GPS.

I have removed use of SERVO until the very end, so we don't need to worry about SERVO/SERVOPOS upsetting the low level timing. For this application we don't need to use the servo until just before we exit.

Both Hippy's idea and mine give the same result - operate the switch and exit as soon as GPS data arrives - those other messages that include ,A,.

Eclectic's idea, in the version below, never gets the required A, so does not operate the switch and exit. Time for me to wait for Eclectic I think :)

Robin
www.gpss.co.uk/autop.htm

Code:
'SC2.BAS iPAQ switch for robot boat
'v1a 13 Sep 2009 (c) Robin Lovelock www.gpss.co.uk/autop.htm 
' see www.Picaxeforum.co.uk
'input is serial RS232 GPS data - to see when GPS is ready
'the GPS outputs text strings and includes ",A," after $GPRMC when ready
'e.g. $GPRMC,114801.000,A,5129.8944,N,00041.0771,W,3.53,358.23,280608,,*18
'output is servo controlling switching of iPAQ power ON
'note that no need to use or hold servo until just before exit

 #Picaxe 08M
 SETFREQ M8 '8MHz for SERIN 

 'wait until GPS ready $GPRMC,114801.000,A,5129.8944,N, etc,etc
waitgps: '
 SERIN 3,N4800_8,("$GPRMC,"),b0,b0,b0,b0,b0,b0,b0,b0,b0,b0,b0,b1
 if b1 <> "A" then 'this idea from eclectic on picaxe forum
   goto waitgps
 endif
 
 'SerIn 3, N4800_8, ( "$GPRMC" ) 'alternative idea from Hippy
 'SerIn 3, N4800_8, ( ",A," )
 
 SETFREQ M4 'standard 4MHz
 PAUSE 1000
 
 SERVO 1,91
 PAUSE 1000
 SERVOPOS 1,126 'toggle servo to switch on iPAQ power
 PAUSE 1000
 SERVOPOS 1,91
 PAUSE 3000 'give servo time to travel then exit
 

eclectic

Moderator
To hear is to obey. :)

@Robin.
If it's just to find “,A,” , then Hippy's program is the simplest and fastest.

The following is just for information.

This reference

http://www.gpsinformation.org/dale/nmea.htm

gives, as an example.
$GPRMC,123519,A,4807.038,N,01131.000,E,022.4,084.4,230394,003.1,W*6A
Seven digits before A

My test was done using an old Rikaline receiver (cheap s/h Ebay job),
whose datasheet gives, as an example.

$GPRMC,161229.487,A,3723.2475,N,12158.3416,W,0.13,309.62,120598, ,*10

Eleven digits before A

Can I suggest something like this program,
so that you can test your receiver.

Code:
#picaxe 08M
setfreq m8

main:

serin  3,t4800_8,("$GPRMC,"),b0,b1,b2,b3,b4,b5,b6,b7,b8,b9,b10,b11,b12,b13
; inputs first fourteen bytes  
 
sertxd (b0,b1,b2,b3,b4,b5,b6,b7,b8,b9,b10,b11,b12,b13, cr,lf )

pause 2000 
goto main

Program was running at 19.54 BST this evening.

e
 

Attachments

hippy

Technical Support
Staff member
Maybe I'm completely missing something, but if looking for ",A," in a $GPRMC message, and that ",A," will always be there, and you're not reading any other data from that string, then why not just wait for "$GPRMC" ?
 

lbenson

Senior Member
If the first value after "$GPRMC," is of variable length, and the second value, comma separated, is either the "A" that you are looking for, or another value, then you could use the following to look at the character which follows the next comma:

Code:
serin  3,t4800_8,("$GPRMC,")
serin  3,t4800_8,(","),b1
if b1 <> "A" then goto waitgps
This assumes that you could enter the second serin in less than the time it takes to receive the intervening characters.
 

eclectic

Moderator
Maybe I'm completely missing something, but if looking for ",A," in a $GPRMC message, and that ",A," will always be there, and you're not reading any other data from that string, then why not just wait for "$GPRMC" ?
@hippy and Lee.

Yes, the simplest way is the easiest.
I hope I stated that in the first part of post #135.

The rest was literally just for background information,
to try and answer Robin's questions in post #134.

e
 

Robin Lovelock

Senior Member
Thanks Folks. Eclectic's GPS is the same spec as mine - in terms of the $GPRMC message, so now I understand why his SERIN statement SHOULD work.

Hippy: the ,A, is only that value in the $GPRMC sentence when the GPS has started tracking. Before that, for perhaps several tens of seconds, the value will be ,V,. These sentences are sent from the GPS every 1 or two seconds. So just doing a SERIN on $GPRMC then a SERIN on ,A, risks ,V, after the $GPRMC (i.e. not yet tracking) but finding it in some other following message.

Thanks LBenson for that alternative way of doing it: I'll give it a try tomorrow. If that works, and since Eclectics did not seem to, I suspect a timing problem in the low level SERIN handling. It's not so easy to do the tests exactly as Eclectics suggests because my GPS is on the roof, cabled into another room: needed because of the iPAQ logic. But I will be doing similar things to track down where the problem is.

Many Thanks to all of you.
Robin
www.gpss.co.uk/autop.htm
 

Robin Lovelock

Senior Member
It Works Gentlemen ! :) Many Thanks to all of you.

The root cause was that the GPS that I am using does NOT have those extra decimal digits at the end of the time - as reflected in the latest version of the program below. I discovered this by following your good advice and echoing back via Terminal what I was receiving - it was worth the hassle connecting up a different GPS. We obviously had some coincidences causing confusion here. I cannot believe it, but all the recorded GPS data I looked at from Bray Lake must have been from a different GPS.

So that modified line from Eclectic worked exactly as it should:
SERIN 3,N4800_8,("$GPRMC,"),b0,b0,b0,b0,b0,b0,b0,b1 'Eclectic
i.e. 4 fewer skips into b0.

Sadly, I could not get the two lines from LBenson to work, even though they look OK, and should cope with different GPS receivers. Maybe it's too late at night for me :)

But this version does what I want, waiting until the GPS is tracking before wagging the relay intended to switch the iPAQ power on.

I see a second one of those reed relays from Maplins is playing up. Hardly the 1 million switch operations claimed for them ! :-( So it looks as if it's time to work on hardware again - maybe even mechanical thingys :)

Many thanks
Robin
www.gpss.co.uk/autop.htm

Code:
'SC2.BAS iPAQ switch for robot boat
'v1a 13 Sep 2009 (c) Robin Lovelock www.gpss.co.uk/autop.htm 
'Thanks to LBenson, Eclectic and Hippy on www.picaxeforum.co.uk
'input is serial RS232 GPS data - to see when GPS is ready
'the GPS outputs text strings and includes ",A," after $GPRMC when ready
'e.g. $GPRMC,114801,A,5129.8944,N,00041.0771,W,3.53,358.23,280608,,*18
'e.g. $GPRMC,114801.123,A,5129.8944,N,00041.0771,W,3.53,358.23,280608,,*18
'output is servo controlling switching of iPAQ power ON
'note that no need to use or hold servo until just before exit

 #Picaxe 08M
 SETFREQ M8 '8MHz for SERIN 

 'wait until GPS ready $GPRMC,114801,A,5129.8944,N, etc,etc
waitgps: '
 SERIN 3,N4800_8,("$GPRMC,"),b0,b0,b0,b0,b0,b0,b0,b1 'Eclectic
 'SERIN 3,N4800_8,("$GPRMC,")
 'SERIN 3,N4800_8,(","),b1 'idea from lbenson on picaxe forum
 if b1 <> "A" then 'this idea from eclectic on picaxe forum
   goto waitgps
 endif
 
 SETFREQ M4 'standard 4MHz
 PAUSE 1000
 
 SERVO 1,91
 PAUSE 1000
 SERVOPOS 1,126 'toggle servo to switch on iPAQ power
 PAUSE 1000
 SERVOPOS 1,91
 PAUSE 3000 'give servo time to travel then exit
 

Robin Lovelock

Senior Member
It Works Gentlemen ! :) Many Thanks to all of you. etc, etc - from August 2009.
Good Afternoon Gentlemen. I've been happily using PICAXE systems for over a year now - to control the servos on my prototype robot boat(s) navigated by iPAQ Pocket PC computer(s).

The reason for this posting is as follows:

Could you remind me what resistor(s) and/or diode(s) I should use on the RS232 input from my iPAQ ? Both iPAQ and PICAXE are powered from a common 5v supply based on 4 D-size 10AH NiMhd cells. i.e. Typically varying from 5.5v down to 4.9v before electronics begins to fail. I'm trying to solve a problem of unreliability in this RS232 interface, after doing the obvious like swapping iPAQs, swapping PICAXE boards, and checking the software. The software has not changed for many months, but the electronics have got wet a few times :)

I'm thinking this problem could be due to the RS232 interface being "marginal" and maybe I can solve it by changing the values of resistors or diodes.

For you amusement, checkout what has been happening over the past year by playing the video linked from my robot boat page www.gpss.co.uk/autop.htm You will fall off your chairs laughing :)

The video shows boat #4 sinking late last year, then being rescued using underwater TV, from 12 feet depth, 60 feet out from the bank. Also, our robot boats doing what they do.

Over two weeks ago, the very first international team - the Welsh one - launched their boat to cross the Atlantic from the west coast of Ireland. Sadly, it failed within 24 hours, but you can still track it, drifting 40 miles off the coast, since the satcoms tracking is working. I've included a link to their updated map. These teams have been talking about it for years - but these were the first to have the courage to try ! We still have time to catch up - maybe :)

Robin
www.gpss.co.uk
 

graynomad

Senior Member
Presumably the iPAQ has true RS-232 and the Picaxe is talking 0-5v. This often works but could well be flaky.

If this is the case the iPAQ may have trouble reading it's Rx and it's Tx could be damaging your Picaxe. You really should condition your Picaxe signals with a MAX232 or similar.

PS: I haven't been following this thread, sorry if I missed something.
 

Robin Lovelock

Senior Member
Presumably the iPAQ has true RS-232 and the Picaxe is talking 0-5v. This often works but could well be flaky.

If this is the case the iPAQ may have trouble reading it's Rx and it's Tx could be damaging your Picaxe. You really should condition your Picaxe signals with a MAX232 or similar.

PS: I haven't been following this thread, sorry if I missed something.
Thanks GayNomad. First I better say that the last time I worked seriously on RS232 was as a student in the 1960s, so - just now - I consulted Wiki and http://en.wikipedia.org/wiki/RS-232 - it was as I remembered from those days: RS232 originally swung between +12v and -12v but, over the years, many devices transmitted at 0v to 5v, and could receive as low as 3v swings.

My very first posting on this thread gives the details of how this PICAXE is being used and why. It seems that, for the past year, I've had a solution that worked reliably. Only now am I noticing the unreliability, and I can't be sure when it crept in.

The test I am using is where the iPAQ moves the servo from -180 degrees to +180 degrees, in steps of 15 degrees. At each step it speaks the angle. The symptoms are that it may begin OK, then maybe after 1/2 or 3/4 way round, it will miss a few steps, possibly to the end of the sequence.

Sadly I'm working without an osciloscope - that would make a big difference.

To answer your question "Presumably the iPAQ has true RS-232 ?" (i.e. +12v to -12v swings), I'm assuming not, but I also assume that the diode I added, based on documentation or this forum, over a year ago, was to protect the PICAXE from large swings. I would expect the iPAQ to swing between 0v and 5v anyway.

I thought I'd seen the problem late yesterday - after consulting the circuit diagram in the PICAXE-08M Servo Driver (AXE024) - linked from my very first posting. There seems to be two resistors on the RS232 input to the PICAXE: a 10k pull-down to ov, and a 22k in series - perhaps part of the protection from larger swings.

It seems my PICAXE here does not have the 10k pull-down - possibly based on the specific RS232 advice from over a year ago. This morning I added a 10k pull-down - the system bahaved exactly the same unreliable way. I then tried adding a 10k resistor across the 22k series - to reduce it: same result.

I've just removed the 10k pull-down resistor, leaving the reduced series resistor, and the test got further - from -180 to +135 before failing. But I need to repeat the tests, in case it was a one-off. Maybe reduce that series resistor more.

But I'd much rather be doing things based on advice from those who have done something similar. It could be software - particularly in the PICAXE - but I want to be confident about the hardware first.

Many Thanks in advance for any info or advice.
Robin
www.gpss.co.uk/autop.htm
 

hippy

Technical Support
Staff member
I would guess that whatever was chosen was on the basis of previous discussions, so it's probably worth trawling this thread and related ones. The moral is, once you have it working, document it. That saves re-inventing the wheel from first principles every time.

Though there's potentially water damage there's presumable a built circuit which can be reverse engineered so you can tell what pull-up, pull-down, current limiting resistors and other components were used and how ? You can probably look at or measure those components to get a rough idea of what their values were.

That would be the logical first step. Even if you can only get 90% of what there was it will be far easier to determine what the remaining 10% should be than starting again with a blank sheet from square one.
 

Robin Lovelock

Senior Member
Thanks Hippy. Good to speak to you again. All good advice, and what I think I have already followed - and, having just read our early postings from a year ago, above, it is comfirmed that yes, it was this Forum, and you in particular, who advised me on those resistors, etc :)

I've just uploaded a 7 minute video, showing all this happening, on
http://www.gpss.co.uk/video/rbpicaxe.wmv

I think you will find it worth watching, even if the last half, waiting for the fault, is like watching paint dry. It shows both with both standard 22k and lower values of that input resistor.

Just to remind you, I have what should be six identical spare PICAXE boards, including the software inside. We are testing a PICAXE that has not been in the water - so the electronics should not be damaged.

My use of a tranny radio may be of interest: to monitor what is happening in the PICAXE software. Has anyone tried this ? I'm not sure how useful the information is, but it makes me suspicious of what is going on inside the PICAXE. It sounds as if there are program loops changing, independently from the application program that monitors the RS232 input and drives the servos. You will hear the radio faintly in the background. I cannot see why it changes tone and pattern, even if the iPAQ is not sending serial data.

The fact that the resistor value changes, but does not fix, the unreliability, and these radio sounds, makes me think we have some strange mix of problem. I really must get use of an oscilloscope, but meanwhile, any suggestions could be of great help.

Finally: my apologies to GrayNomad eariler. That really was a simple typo when I said GayNomad :)

Robin
www.gpss.co.uk/autop.htm
 
Last edited:

Robin Lovelock

Senior Member
I have some new information, having got use of a 'scope, and - so far - it confirms my suspicion that changing the 22k input resistor value is masking some other problem.

It seems the "RS232" input from the iPAQ normally sits at -6v, below the ov level, then pulses up at +6v when sending data. This is what I see on the iPAQ side of the series input resistor. On the chip side, I see it sitting at 0v, pulsing at the +5v supply level. Signals looked clean with little or no noise.

Levels were confirmed by tapping the 'scope probe on the +5v supply. I must confess that ity took me some time setting up this had-held Maplins scope, borrowed this morning from a friend. It's also many years since I used a 'scope :)

I'm wondering if using just a series resistor and one diode (as suggested early on this thread by Hippy) is sufficient. I could obviously experiment, but Hippy may have some suggestions.

Robin
 

hippy

Technical Support
Staff member
The voltage levels at the PICAXE pins look okay. I'd have expected the low to be slightly negative but it depends on what is in the circuit; there could be a blocking diode to remove negative voltages, and any slightly below 0V and slightly above 5V may not be immediately obvious unless looking for them.

I'd say the hardware seems fine; it appears to be a good, clean, full-voltage serial interface, so any issue are probably somewhere else.
 

Robin Lovelock

Senior Member
Thanks Hippy. It sounds strange if that resistor change is masking software problems. If we go back to the postings on this thread of over a year ago, I got the system working by following your advice - but now I'm thinking the software may have been "marginal" reliability.

I remember you saying that the approach we used inside the PICAXE meant that my three bytes (first is a sync byte) should be preceeded by blank bytes to "wake up" the process inside the PICAXE. If I start making more changes in the iPAQ, to program around restrictions and/or bugs inside the low level PICAXE software/firmware, I'd rather do it based on advice from you.

Also, it raises again the question of what patters of sounds I hear on my Tranny radio, from the PICAXE - with changes of tone and pattern - even when the iPAQ is not doing anything (e.g. switched off).

It raises questions on what the hell is going on inside the PICAXE. There are obviously timer processes beyond what you and I have programmed at the application level. My actual source, based on your good advice, is in the thread above. Nothing been changed for over a year, of course.

After thinking what might be happening, I can make software changes in iPAQ or PICAXE - but not a good idea to do at the same time ;-)
"Change a little then test a lot"

Robin
www.gpss.co.uk/autop.htm
 

hippy

Technical Support
Staff member
I have to admit you have me, and probably everyone else, at a bit of a disadvantage in trying to recall all the discussion so long ago and I haven't had the time to read through what's gone before.

I'm not sure if the tranny radio warbling is of any real use or not; the effect is well known but it doesn't necessarily point to good or bad. There is indeed a whole lot going on in a PICAXE while crunching through a program and when waiting for input, internal hardware timers ticking along. You are picking up side-bands of EMF, much like a bat detector converts ultrasound to something audible, so it's difficult to say how what you hear relates to what's actually happening and it will vary naturally over time. Clever coding and careful tuning can even get a microconroller to play a tune over the airwaves!

If it was working, now isn't, then something's changed. The question is what. Is it an unforeseen problem ( such as GPS / RTC having a different data ), or is it a systemic issue which has only now revealed itself, is it an iPaq issue, a PICAXE issue or something else ? I'll see if I can find any time to get up to speed.
 

Robin Lovelock

Senior Member
I have to admit you have me, and probably everyone else, at a bit of a disadvantage in trying to recall all the discussion so long ago ... etc.
I've just been looking through this long thread - thought I'd better save you time doing the same. I may be coming back later with an apology.

Only now do I see that, after getting it working reliably as a servo controller, we then added the function of a watchdog timer and power switch - MAYBE THE EXPLANATION FOR THOSE STRANGE RADIO SOUNDS ?

I'm working on a simpler version, with the watchdog timer and power switch function removed. I see that there was later discussion on looking at the GPS data, but that was always done in a different PICAXE - not yet in the system.

So I may be getting back to you soon with more news.

Robin
www.gpss.co.uk/autop.htm
 

Robin Lovelock

Senior Member
IT'S WORKING RELIABLY ! :)

Solution was a simpler PICAXE program, just doing the reading of input from RS232 and driving the two servos. The watchdog timer and power switch was removed. As I write this, it is doing it's 4th test run - no failure yet - before it did not complete even one.

Strange that the input resistor value effected it - but no worries.

Now the apologies and explanations...

Sorry for your time on this, and many thanks: it has helped in my deciding to look again at the software. Wierd how the radio made me do this - but read below.

I can only assume that much of my sailings over the past year were with the Klaus card instead of the PICAXE (with the watchdog timer logic). Also, much of the past year has been spent solving other problems with the boats. The old,old story of thinking you are using a component that was thoroughly tested - my early picaxe software version may have been tested properly - but obviously not the version in my spare chip !

I also found out something important: I had not been tuned in to the PICAXE with my radio, but the nearby (digital) radio control receiver. Those changing tones were obviously it searching for the transmitter - which is switched off. When I tune in to the PICAXE - I get what I expect - a regular pattern of tones - only changing when data arrives from the iPAQ.

Have a nice weekend everyone - and many thanks again Hippy.
I'm sure Snoopy will be sailing again next week ! :)
Robin
www.gpss.co.uk/autop.htm
 
Top