PICAXE handling GPS for robot boat

eclectic

Moderator
Very sensible of you.
It's a bit like owning a (Insert car) basic model.
Then finding out that you can buy the
"GT Rally spec" for the same price. :)

In the meantime, have a play with this:

Code:
#picaxe 08M
setfreq M8

main:
serin 2,t4800_8,("$GPRMC,"), b0,b0,b0,b0,b0,b0,b0,b0,b0,b0,b0,b0,b0,b0,b0,b0,b0,b0,b0,b0,b0,b0,b0,b0,b0,b0,b0,b0,b0,b0,b0,b0,b0,b0,b0,b1,b2,b3,b4,b5,b6,b7,b8,b9,b10,b11,b12,b13
sertxd ( b0,b1,b2,b3,b4,b5,b6,b7,b8,b9,b10,b11,b12,b13, cr,lf)

wait 1
goto main
You may need to adjust the number of discarded b0.

e
 

hippy

Technical Support
Staff member
Would also be good if the code did not depend on the precise sentence coming out of the GPS. i.e. it would still work, whatever NMEA GPS we plugged in.
I would say forget making it work with whatever is plugged in for now and instead choose a GPS and write the program to work with that. As NMEA is a standard I can't see that packets would differ much between GPS brands and it should be possible to change the program to suit any GPS when you come to choose one. It's not like a PC where there's no control over it once shipped, a user can plug in whatever they like and it has to cope with everything up-front; if you have to swap GPS it's just as easy to load the tailored code for that GPS at that time.

I'd also say take a step back, assume whatever you want can be done, decide what you actually want to do, determine how (conceptually/algorithmically) it would be done, then choose a PICAXE based on that to do it. At the moment the project feels back-to-front to me, being driven by what a particular PICAXE may or may not be able to do, not by what you want to achieve, trying to work out how to without knowing what actually needs to be done.

And put aside the issue of variant or cost of PICAXE; even the most expensive will only be a small part of a venture of this scale.
 

Robin Lovelock

Senior Member
Thanks Eclectic and Hippy. I was tempted to try that long input statement Eclectic, but, even if I fixed what GPS I used (Hippy) I think, by the time you get to the GPS heading field, there are fields before that will vary in length - so that "searching for commas" logic would be required - so I think I'll resist the temptation to try that long SERIN :)

Earlier today, when I got the simple SERIN and SERVOPOS stuff working together, I looked at the earlier threads, and looked for what I needed to speed things up. I tried your faster statements, Hippy - but of course they were rejected. The PICAXE site did not seem easy for me to find that magic 08M2 - until Eclectic gave me the name.

Sensible words of course from you, but for me the few pounds on PICAXE bits is not the significant thing - its the time spent getting a solution together - and I count each hour. That earlier thread about using a PICAXE as a timer was aa good example. I got what I needed - but I might have wasted days if I'd followed some of the advice.

What I like about this Forum is that you get rapid feedback, and usually get the answers you need quickly - within hours rather thaan days.

You obviously get the occasional person who hasn't looked at the relevant page and may sound like they are telling "grandma how to suck eggs" - but then even they sometimes come up with some lateral thinking - or something that could be useful. e.g. use of a cheaap etrex and it's $GPBOD sentence.

I'm hoping that next week, after I fit the faster chip, and get that SERIN stuff from Hippy to work, I'll soon have a usable AUTOP1.BAS solution.
I caan think of what might be very minor additions, that would make it do morte than simply "steer west" - or whatever heading is needed.
e.g. use of the Latitude - crudely - just the degrees - to change heading steered, to go south west, then follow the trade winds west.

Hope I've not rubbed anyone up the wrong way - I really do appreciate all the postings - most are immediately useful and save me hours of work.

If "work" is the right word for anything that is PICAXE-related :)

Robin
www.gpss.co.uk
 

Graham O

Member
Hi Graham - thanks for that early posting. Now that I've got the servo control to work with SERIN, I'm ready to try what's needed to read that GPS data.

What sort of SERIN statement(s) were you using ? Maybe something to read enough bytes with SERIN into a byte array ?
If I can get that far, I can see it should not be too difficult to scan the array, counting commas, to extract the fields required.

Robin
I write all the input from the GPS into the scratchpad area of a 28X2 with

serin c.1,t9600,("$GPGGA"),@ptrinc, .....@ptrinc,@ptr.

Then go through counting commas to get to the time, altitude, latitude and longitude. Format each value and write it to another area of the scratchpad to produce an output data packet for transmission to the ground.
Whenever I read on here how elegantly other people do things, I always feel that mine is a bit clumsy, but if it works, that's good enough for me.

Graham
 

Robin Lovelock

Senior Member
Thanks Graham. As you can see from the earlier postings, I'm hoping I have a simple solution based on a plug in faster chip and Hippy's code.
Time to switch off this PC now :)
Robin
 

MPep

Senior Member
I would say forget making it work with whatever is plugged in for now and instead choose a GPS and write the program to work with that. As NMEA is a standard I can't see that packets would differ much between GPS brands and it should be possible to change the program to suit any GPS when you come to choose one.
A stasndard - Yes, one that all manufacturers agree upon - No.
As NMEAS sentences are delimited using commas, you have 2 options.If there is a field that you have no data for you can opt to have a null field ie: ",,", OR you can provide 'zero' data ie ",0.0,".
The other problem is that of variable length fields. Consider speed for instance. you can have ",5.5," or ",15.2,". As can be seen, when a tens digit is required it is added. A more useful variation would be to have ",05.5,". Make a fixed length data field, but generally doesn't happen.

Lots of options, but there is no fixed structure to the data fields.
The data sentences are set, and all manufacturers must comply to it, but the individual fields are not fixed in the standard. Very frustrating, but that is the way it is.

Hope this helps.
MPep.
 

Robin Lovelock

Senior Member
Hi Folks. While I wait for my faster chips to arrive, I thought I'd put down my thoughts and questions here, and some bacground to answer some basic questions raised by one or two of you. e.g. why was I not selecting the right components in the first place ?

First the background: this really "austere" picaxe based autopilot is very much a recent idea, and - believe it or not - started with me considering launching a boat from the UK coast with little more than the essential (and most expensive) satcomms tracker. Not so difficult if I were in Portugal or north Africa - to exploit the trade winds going west, but much more tricky from UK. I was thinking of a little model yacht, trimmed to sail close to the wind on the starboard (right) side. i.e. it would go south-west when the wind blows from the west. At least it would test the GPS-satcomms. But then I thought a very simple and crude PICAXE-based autopilot might do much better. Don't forget that it would not matter where the boat ended up - we would know where it was from the satcomms, reporting at least once per daay.

Of course, for the past three years, my main solution is based on an iPAQ - and at 25 GBP off e-bay, it's not the money that's significant - it's the consequent increase in power consumption, followed by enough solar cells - and consequent minimum size of boat: probably more than a metre long, unless very broad. Use of an iPAQ has meant simplicity in the software, with lots of extras possible to be bolted on easily for local testing on lakes - like the voice reporting viaa FM and/or PMR. All this stuff can be seen and heard in the "Snoopy Sails!" video on www.gpss.co.uk/autop.htm

Now my latest thoughts and questions: I'm hoping that, when the faster chips arrive next week, I'll be getting those Hippy SERIN statements to work - already tested by Eclectic. Hopefully my test program will quickly be waggling a servo based on if the GPS is tracking, as it does now, based on Eclectic's old SERIN. But then I can exploit the GPS heading item as intended - to steer the boat. I will obviously be measuring power consumed, including for the servo - already chosen for low power consumption for the recent bottle tracking project (www.gpss.co.uk/bbcbot.htm).

Looking at what can be extracted from that $GPRMC GPS sentence, it seems to me that the following should easily be exploited:
the "A"/"V" value to determine if the GPS is tracking.
the GPS heading, to see what direction the boat is moving, if going faster than typically 0.5 knot.
the GPS speed, to check this, and if the GPS heading should be trusted.
the first two digits of latitude (e.g. 51) to allow a crude adjustment of target heading as the boat moves south.

I've always assumed it would be a waste of time trying to extract and exploit numbers beyond simple integers, like heading and speed. Mostly because of the lack of support within the PICAXE software - to extract the real numbers (or scaled integers), let alone do any arithetic with them - like calculaate the bearing between two lat/lon positions. I remember the "joys" of doing this in assembler in the 1960s - but even then we had a library of subroutines to do it :) If some of the bigger PICAXE chips have this capability, and supporting software, that'll be good to know - but I doubt if I would switch to those chips at this time, for the reaasons given earlier.

I've got a couple of PICAXE servo driver kits still in bags, unused from the bottle tracking project, so I intend to assemble them soon. I must try and remember the extraa diode and resistor needed to wire in the serial input from the GPS. Note that the GPS is the usuaal type, with it's output swinging between USB 5v levels. It'll be on the PICAXE site somewhere, and in my earlier postings. If someone remembers, that may save me time finding it. This time I'll put the components in on the correct side of the board before soldering them - yes, that was an embarrasing thread started by me some time back :)

Robin
www.gpss.co.uk
 

srnet

Senior Member
I've always assumed it would be a waste of time trying to extract and exploit numbers beyond simple integers, like heading and speed. Mostly because of the lack of support within the PICAXE software - to extract the real numbers (or scaled integers), let alone do any arithetic with them - like calculaate the bearing between two lat/lon positions. I remember the "joys" of doing this in assembler in the 1960s - but even then we had a library of subroutines to do it :) If some of the bigger PICAXE chips have this capability, and supporting software, that'll be good to know - but I doubt if I would switch to those chips at this time, for the reaasons given earlier.
PICAXE basic does not support the trig and floating point maths needed for this type of application. I have built a RC Lost model beacon, see picture. Its based on a 18F25K22 and programmed in Mikrobasic. This language supports the trig and floating point and when a GPS is connected to the locator it can calculate it position and direction (from a home fix) to within 5M and 1 degree over a few KM.

I have a V2 PCB to build, same size, which can be switched between a 18F25k22 SOIC and a 28X2 and adds a RTC. However when built with a 28X2 it cant calculate direction and location from home, it really needs a GPS unit that supports the distance and direction to waypoint output.

But in your case you dont actually need to calculate direction and distance to a known location. If you were to strip out the lat and long from the NMEA string and convert from the NMEA format to decimal degrees, all you would need to do is check the differance between the current values of lat and long and the values of the destination, then navigate in a way that the differance gets smaller.
 

Attachments

Last edited:

hippy

Technical Support
Staff member
PICAXE basic does not support the trig and floating point maths needed for this type of application.
I haven't tried it but I'd have thought the PICAXE would be able to do the maths and give a reasonable result. One solution would be to emulate floating point and trig routines and there's always the uM-FPU maths co-processor - as that uses I2C it can be used with M2 as well as X2 PICAXE.

Accuracy and resolution always becomes an issue, especially with points close together where number differences are small and fractional. For further distances, and a small boat at sea which likely won't actually follow the heading set anyway, lower resolution may be acceptable.

Obviously one doesn't want a homing beacon finder alternatively tacking you NW and SW when you're meant to be heading W on foot and ideally want the shortest distance to the beacon but it may be satisfactory for this project.

Floating point emulation code isn't that hard to create, trig functions a little more difficult; it's just finding the time to do that and testing the results achieved.
 

srnet

Senior Member
I haven't tried it but I'd have thought the PICAXE would be able to do the maths and give a reasonable result. One solution would be to emulate floating point and trig routines and there's always the uM-FPU maths co-processor - as that uses I2C it can be used with M2 as well as X2 PICAXE.
uM-FPU is a possibility, a bit on the large size though, if only they did a 8 pin SSOP ....

The distance is not so much of a problem, its the bearing thats the issue, it needs to be accurate to within a degree or so.

The idea here is that the beacon establishes a home location and then continually calculates the direction and distance from home, it then transimits it as slow speed morse which is easy enough to decode by ear. All you need then is the radio, a PMR cheapo will do (to listen to the morse and beacon tones) and a compass. A map makes it really easy to work out where the beacon is, although for anyone practiced in navigation the distance and bearing is quite adequate.

The use of morse might seem a bit retro, but it is possible to decode on a very weak signal, you can plug the radio into a netbook and decode that way if you must (tried it, does work).

Although this might all seem complex for a Lost Model Finder, it comes from a desire to simplify what gear you need, and it has to be small The idea of using GPS for this has been mooted before, but from the perspective of transmitting the Lat and Long, which is really not that useful.
 

srnet

Senior Member
uM-FPU is a possibility, a bit on the large size though, if only they did a 8 pin SSOP
Whoops, its the V3 that is the larger, mind you a very interesting device, it even accepts a GPS input and does NMEA string parsing.
 

MPep

Senior Member
Looking at what can be extracted from that $GPRMC GPS sentence, it seems to me that the following should easily be exploited:
the "A"/"V" value to determine if the GPS is tracking.
the GPS heading, to see what direction the boat is moving, if going faster than typically 0.5 knot.
the GPS speed, to check this, and if the GPS heading should be trusted.
the first two digits of latitude (e.g. 51) to allow a crude adjustment of target heading as the boat moves south.
If you only use the first 2 digits, then your variation will indeed be great!

If you do intend on using an eTrex type system, the eTrex outputs the RMB sentence. With an active route, you will see it contains Cross-track error, and direction to steer. Also includes distance to waypoint.
Whilst most folk have heard of the RMC sentence, as it contains everything about what you are doing right now, the RMB sentence was 1 of the first autopilot sentences around.
The RMB sentence also has the A/V check bit.

NMEA data samples can be found here
 
Last edited:

morrismarine

New Member
Having sailed across the atlantic this is of interest, partly as it would be much easier to set the yachts going, get off in a rib and then fly over and spend the 2 weeks in the caribean waiting for it to turn up.

I cant access the videos so i may be talking about things that you will have already covered but it seems simply waggling the rudder when your pointing anything but due west will fail to steer a course, if you can set the model so it will self tack and that would be adviseable so it cant heave to and effectively stop, you could then describe a dead band that it would tack up, which can either be between two latitude values or using cross track error from a goto waypoint. In a navigation sense you tack the angles to windward sailing out to 30' from the destination point and then tacking with each tack getting progessively shorter the idea of this rather than two big tacks is to minimise the error caused by windshifts.

the advantage of this is the model could be set to self steer a best course to windward with a small amount of helm applied to keep a straight line and then all the gps, and picaxe are trying to do is too determine the time to tack.

Otherwise to steer a course your really going to need a wind direction so that the system to decide to ignore an incorrect heading beacuse its a place that it cant point to, and a compass would be helpful too, as if you rely solely on gps direction and point straight into the wind the speed will stop, and the direction will slowly go round in circles but you will then lose the sense that the direction is the way the boat is pointing and the helm may not be applied in the correct direction to get it sailing again. anyway will keep an eye out for it.
 

srnet

Senior Member
Shirly by now someone has programmed a PIC or similar micro to act as a GPS engine interface to a GPS module ?

Along the lines of the serial to LCd driver.

A programmed micro that accepts the serial input from a GPS module and can (via another serial or I2C connection) be controlled from another micro. So you send a serial or I2C command to request a Lat & Long fix. Or you send a home or destination fix and it returns a distance and direction.
 

MPep

Senior Member
Shirly by now someone has programmed a PIC or similar micro to act as a GPS engine interface to a GPS module ?

Along the lines of the serial to LCd driver.

A programmed micro that accepts the serial input from a GPS module and can (via another serial or I2C connection) be controlled from another micro. So you send a serial or I2C command to request a Lat & Long fix. Or you send a home or destination fix and it returns a distance and direction.
Shirley has. :eek: Check here: DIY Drones. May not be quite what you had in mind, but could be adapted (recoded) for any other purpose.
 

MFB

Senior Member
Sernet. There is a preprogrammed PIC chip available that parses selected GPS sentences and even FSK modulates the data for telemetry transmission. Its quite popular with the ballooning crowd (think its called something like Traxs).

Parallax do a GPS board that has a dedicated micro for interfacing with a Basic Stamp, which probably needs all the help it can get!
 

srnet

Senior Member
MFB, I cant find what you refer too.

I dont need one, I have done the coding already in Mikrobasic, fits easily in 18F25K22. No doubt if it were written in C or assembler, you might get it in a PIC with 16K flash.
 

Robin Lovelock

Senior Member
Thanks Folks - particularly Mpep. That link to the Garmin $GPBOD section (pasted in below) was particularly useful.
i.e. the "WARNING: this is the bearing from the moment you press enter in the GOTO page to the destination waypoint and is NOT updated dynamically!"

My priorities are still as posted earlier: to get Hippy's code working after I've dropped in a faster chip.
I'm confident that, if it works, I could make a simple Autopilot to hit South or North America - maybe within 100 miles of a spot.
Sorry that some of those other recent posters need to watch the video or read the page more closely for answers.

Mpep has saved me some wasted time, getting a solution working based on a Garmin etrex - looked nice of using $GPBOD to guide accurately to the destination.

I checked my old etrex here - draws 120mA with backlight off - only two or three times more than a simple GPS mouse, so not too expensive on extra solar panels and deck space. Would probably get one for 50 or 60 GBP instead of 15 to 20 GBP for a GPS mouse.

But fiddling about operating the "goto" would probably make the whole exercise too complex and error prone.

Thanks Mpep :)

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

$GPBOD
Bearing Origin to Destination

eg. BOD,045.,T,023.,M,DEST,START
045.,T bearing 045 degrees True from "START" to "DEST"
023.,M breaing 023 degrees Magnetic from "START" to "DEST"
DEST destination waypoint ID
START origin waypoint ID

Example 1: $GPBOD,099.3,T,105.6,M,POINTB,*01
Waypoint ID: "POINTB" Bearing 99.3 True, 105.6 Magnetic
This sentence is transmitted in the GOTO mode, without an active route on your GPS. WARNING: this is the bearing from the moment you press enter in the GOTO page to the destination waypoint and is NOT updated dynamically! To update the information, (current bearing to waypoint), you will have to press enter in the GOTO page again.

Example 2: $GPBOD,097.0,T,103.2,M,POINTB,POINTA*52
This sentence is transmitted when a route is active. It contains the active leg information: origin waypoint "POINTA" and destination waypoint "POINTB", bearing between the two points 97.0 True, 103.2 Magnetic. It does NOT display the bearing from current location to destination waypoint! WARNING Again this information does not change until you are on the next leg of the route. (The bearing from POINTA to POINTB does not change during the time you are on this leg.)
 

srnet

Senior Member
Out of interest if one was uses the 'Goto Waypoint function' of the Garmin, which I presume you instigate from the devices keypad, what happens if the Garmin resets, or has a power interruption ?
 

Robin Lovelock

Senior Member
Good Point srnet: even more reasons why use of the $GPBOD might not be practicable. I just took batteries out of the etrex, and put them back in: as expected, you then need to press PWR ON - but - the real killer - you need to reselect the destination waypoint. So the design cannot afford to have an etrex power failure.

But no Probs - since that's not the present intention - but it was worth considering.

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

Out of interest if one was uses the 'Goto Waypoint function' of the Garmin, which I presume you instigate from the devices keypad, what happens if the Garmin resets, or has a power interruption ?
 

MPep

Senior Member
Hi Robin,

Glad I could help.
Regarding the loss of function in a power down situation, can't cover all bases ;-(. However, in a permanently ON DC vessel such as yours, I don't foresee problems. But you need to prepare for any eventuality.

MPep.
 

Robin Lovelock

Senior Member
Most of the solutions, including the "proper" ipAQ one, will still work if they lose all power but then the sun turns them on again.

Earlier this evening I plugged my etrex into a Laptop running Windows Terminal and walked around a waypoint on my front drive, with the etrex set to GOTO waypoint. It confirmed what the documentation says - the bearing does NOT update as you move your position around. This was the real killer.

So looking forward to getting those faster chips, probably Tuesday, to make up several crude PICAXE autopilots, for "disposable" boats.

Meanwhile the really major task continues - a practical, affordable and RELIABLE means of tracking in the middle of the Atlantic - at least one pisition report per day. SPOT and Iridium are two options, but tomorrow I have a HAM radio friend visiting to discuss a few APRS related options like "wspr". Sorry this is not the place to discuss, but I'm always pleased to receive ideas. e.g. that TinyTrack URL earlier - see my ancient radio page - www.gpss.co.uk/radio.htm

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

MPep

Senior Member
Earlier this evening I plugged my etrex into a Laptop running Windows Terminal and walked around a waypoint on my front drive, with the etrex set to GOTO waypoint. It confirmed what the documentation says - the bearing does NOT update as you move your position around. This was the real killer.
That's why I mentioned a seperate fluxgate compass to provide heading under all conditions.
Remember that a GPS is nothing more but a fancy calculator, that relies on signal differences to work out the current location. Therefore you must be moving in order to get a 'calculated' sense of direction. When you are stationary, your speed, direction , L/L are always changing!
I suppose that you could get a gyrocompass in there, but the cost would be prohibitive!
 

Robin Lovelock

Senior Member
Hi Mpep. Take a look at www.gpss.co.uk/autop.htm and scroll down to near the very bottom and "early thoughts from May 2008". You will see that fluxgate compass was on my list for the most obvious solution. Nothing is absolutely fixed, and if I'd found (or still find) a really low cost, reliable, and easy to interface compass - that might still be used. It could even be used in a simple solution without any GPS at all - although it would then be even cruder than the crude PICAXE-only autopilot I'm considering now.

As it happens, John - www.team-joker.com - who first got me going on this daft robot boat stuff, suggested I use the GPS heading, but I always thought it would be too unreliable - particularly due to inaccuracy at low speed. However, after three years of tests of our prototype boats, all of which including logging of the GPS data, I've recently decided that use of the GPS heading is worth a try. If you watch the video of "Snoopy Sails!" and listen to the autopilot speaking, you will hear it calling out the distance and direction to the next waypoint. The direction (e.g. "minus ten degrees") is based on the difference of GPS heading with the bearing to the next waypoint. All this stuff was easy to do on the iPAQ, exploiting what was aalready in my GPS Software product. Please don't forget that this is still my "proper" solution. But sometimes "cheap and nasty" is not so nasty after all :) The biggest attribute looked for in the overall solution is resilience aand reliability - for many months at sea - particularly the occaasional storm !

Looking forward to today's chat with my radia HAM friend, and maybe assembling some more PICAXE boards. Then maybe the faster chips will arrive tomorrow ....

Robin
www.gpss.co.uk
 

MFB

Senior Member
I'm using a HNC5883L three-axis magnetometer for attitude measurement on an RC aircraft. Small, low power, cost less than £10 and only needs an I2C interface.
 

srnet

Senior Member
Well you can use GPS to get the direction you are pointing, even when stationary, but how long a boat you need to make it workable, I dont know.

As for HAM radio type solutions, I envisage considerable difficulty making it reliable, give the obvious power and antenna issues. One other one to consider however is QRSS (very slow speed morse) which is capable of retrieving data when the wanted signal is on the noise floor.
 

Robin Lovelock

Senior Member
Hi PICAXE Folks. This is only for radio amateurs (HAMs) among you - and I know there are a few.
I've just posted it onto the Microtransat forum - sorry not a link but a mailing list of participating
teams around the World. To know more, follow the Microtransat link from my page.
Maybe someone can build and "operate" a WSPR solution soon ?
Maybe the (radio HAM) rules permiit their callsign to be used for more than one boat and team.
Robin

Hi Folks. Later this week I may have a very low cost, simple and reliable
autopilot solution working, based upon little more than a GPS, PICAXE and rudder servo.
I'll put more onto my robot boat page later this week. www.gpss.co.uk/autop.htm

This was partly prompted by recent conversations with the Aberystwyth team,
in which I said I might bring along one of our boats to view, but not compete.
I must admit, it would be nice to have something, based on what I already have,
which might be reliable enough to survive a few months at sea, and MIGHT get there.
More about the boat and simple autopilot later this week.

The reason for this posting is how I can do the long range tracking.
Our recent BBC bottle tracking was great fun - but not relevant: www.gpss.co.uk/bbcbot.htm
Although there has been some spin-off like modelling of tides, etc, electronic components, etc.

Today I had a chat Roger, my local radio amatuer (HAM) friend, about WSPR, and I'm also
discussing this with Klaus. Both are on my old (1999) radio page www.gpss.co.uk/radio.htm
with a few words added today, and links to WSPR (on Wiki) and my robot boat page above.
I hope you like my choice of picture - the relaunch of Snoopy Sloop 4 with a "casual throw"

What is the minimum accuracy to qualify for the daily (or more often) position reports ?
I guess 1 degree of lat and lon might not be enough ? i.e. within 100 miles ?
Would 1 minute of lat and lon be good enough ? Nearer 1 mile precision ?
This effects the details of how WSPR message is used to carry the GPS lat/lon position.

Maybe there are some radio HAMs out there among you. Sadly my friend Roger may be able
to help me in the longer term (e.g. next year) but not in the next week or two.
From our discussion - and the few words now on that radio page above - it seems
that a WSPR based solution could be put together by a knowledgeable radio HAM,
for the cost of just a few tens of pounds Sterling. But this GPS-WSPR transmitter
on the boat(s) would need to be "operated" by that same HAM, using his callsign.
This also has to be done carefully within the rules, and may need formal approval.
The big benifit is not just the low cost of transmitter hardware: it is that the transmissions
will be picked up by the massive number of HAMs around the World, who have PCs listening
out for WSPR transmissions. We are talking of ranges across the Atlantic and beyond.

SPOT and/or Iridium sateelite based comms and tracking has always been the serious contenders.
In fact, I think it was I who first relayed my friend Klaus's suggestion of SPOT to this forum.
It seems that a SPOT messenger could be purchased for 100 GBP, plus air time of 100 GBP,
and used after a suitable minor addition of an electronic timer closing contacts on a button.
(I'd love to hear more specific detail on any low cost SPOT solution).

My problem is that even SPOT, at maybe 200 GBP, is the majority of cost (excluding my time),
for any simple, low cost, robot boat solution. Reaching into my pocket to spend more money deters
my putting solutions together early enough for them to be properly tested.

I have the suspicion that others among the Microtransat teams may share the same problems.
How else can we explain that after what must be over 5 years of talking about Microtransat,
and numerous international meetings - some near the sea side - there has only been one attempt ?
i.e. the heroic voyage of Pintar last September.

I cannot believe it is "fear of failure". Pintar failed to cross the Atlantic, but can be admired
as being the first to try, and I'm sure a lot was learned from it. e.g. both SPOT and Iridium failed
- but of course, we don't know why - including maybe Pintar was swallowed by a whale

My approach is to make sure I always have a "toy" to play with. This year that toy has been Snoopy Sloop 5 - the star of the "Snoopy Sails!" video on www.gpss.co.uk/autop.htm - but he has given lots
of useful data, and continues to do so. e.g. that spoken distance and direction to the next waypoint, and the PICAXE servo controller, is the basis of my much cheaper autopilot solution.

But more about that in a few days time.
There is no point in making a suitable boat and guidance system if we cannot afford to track it

Low cost remote tracking of a small, low costboat is now my priority concern,
even if - in my view - it was always the only essential for Microtransat.

Robin
www.gpss.co.uk
 

srnet

Senior Member
It is that the transmissions
will be picked up by the massive number of HAMs around the World, who have PCs listening
out for WSPR transmissions. We are talking of ranges across the Atlantic and beyond.
Interesting, but based on what power and what antenna ?

Any examples ?
 

Paix

Senior Member
Hello Robin,

It might be easier to put a transponder on a satellite than a row boat.

http://licensing.ofcom.org.uk/binaries/spectrum/amateur-radio/guidance-for-licensees/samplelicence07.pdf

This will give you something to get your teeth into and dispel a few myths about what is permitted and what isn't.

The problem might be the regulations for unattended operation. A bit difficult to have someone switch off your creation within 30 minutes if it is required by the authorities. And unattended operation in international waters, Hmmmmmmmm.

That would also require a full licence to operate on the high seas. /MM no doubt (postfixes optional)

Ian - G0PAi
 

manuka

Senior Member
WSPR (Weak Signal Propagation Reporter),is essentially a 3-30 MHz propagation insight technique for use at a fixed location, but "may" have some mileage. WSPR uses K1JT's MEPT_JT (Manned Experimental Propagation Tests, by K1JT) digital mode at a low transmit power level (typically ~100mW-2 W). Check a WSPR overview ,along with decoding software insights. A decent antenna is essential, & as you'll probably only be good for a short whip, tx performance could be degraded.

FWIW an acclaimed (and PICAXE controlled!) ~US$55 WSPR kit has just been released by US ham W5OLF ("Jay Wilson"). He's apparently selling via EBay? Naturally operation by a licenced ham is intended. Jay's kit works on ~10MHz & is good for 2 Watts, but you'd need a solar panel to charge a 12 V SLA that powers both this & associated GPS/PICAXE hardware. Even trivial things like encrusted salt spray could seriously degrade PV performance of course.

Again I ponder the seaworthiness of the boat itself is really the major design issue...
Stan. (ZL2APS -since 1967)
 

Attachments

Last edited:

knight

Member
I'm a radio amateur, but am not a legislator so take what i say below with a grain of salt.

My understanding is that, no, you couldn't just put a amateur transmitter on the boat and send it off using a normal callsign.

However, what is permitted is unattended operation of repeaters and beacons, now repeaters are not much use for your situation, but if you talked to your equivalent legislative authority you may, and i stress may, be able to get a beacon licence for the boat itself, the purpose being to test amateur radio propagation throughout the Atlantic ocean. Then the boat would have its own callsign which it would have to transmit along with its data. Because lets face it, you are basically building a beacon (a beacon that moves and floats yes, but a beacon none the less)

The other issue you will face is that while the UK legislative authority may authorise it, beacons, unlike amateurs, usually don't move much, so I doubt there would be a recognition of licence agreement for a beacon licence with other countries.

Just a couple of thoughts for you

Knight
VK2LBP
 

manuka

Senior Member
Well said- my view as well! All up perhaps Robin should just bite the bullet & install a ~160MHz marine AIS Class B transponder.These typically cost £500, but will also alert other vessels to the nature & course of his darling. Satellite reading of these is now underway too.

As mentioned before,a few hundred quid is probably near trivial beside costs involved in the overall seaworthiness of an unmanned ocean going vessel. Back in 1999 our local Trans-Tasman unmanned venture had >£20,000 (in todays money) thrown at it,but even then the dinghy sized craft proved not up to the task... In the spirit of Trans-Tasman rivallry I even teasingly offer the 1995 plight of their "Australia One" during an Americas Cup race.

Old salts no doubt recall "A boat is a hole in the water, surrounded by wood, into which money is poured"
 
Last edited:

srnet

Senior Member
So if you were to operate a WSPR beacon outside the territorial waters of the UK & USA, what licencing conditions apply, possible none ?
 

Paix

Senior Member
More than one I would imagine. Bit of a minefield. In space it's less difficult as that isn't carved up like the oceans.

You are probably good with UK licensing within UK territorial and international waters, but once you hit the territorial waters of another nation or possibly move into different ITU regions the regulations and possibly the band usage cab change.

I think that even under one administration a mobile beacon is a bit of a misnomer and would meet all sorts of regulatory issues taking you well clear of your available timescale.
 
Top