Suitability for High Altitude Ballooning

[MFB]

Having successfully used the PICAXE for a number of model aircraft and rocketry projects it seemed logical to continue this approach when starting on a high altitude balloon (HAB) payload. However, on visiting http://ukhas.org.uk/ I was surprised at the dismissive comments about the PICAXE, with the majority of examples being aimed at the Arduino. Following a brief comparison between the two devices it was by no means obvious to me why they should have reached this conclusion.

Personally I find C++ to be rather verbose compared with PICAXE Basic, when for example implementing multiple serial ports with their own time-outs. Yes, Arduino does have lots of support libraries but then its not even possible to implement I2C without one. Unless you need the speed (and most HAB telemetry is only 50bps) or floating point maths, I would have thought the PICAXE was quite adequate for the task ( just look what sernet did with the $50 Satallite!).

Are there any Habbers out there that can provide examples of PICAXE based projects?

 

[eclectic]

Two here as a starter:
http://www.picaxeforum.co.uk/showthread.php?15801-High-Altitude-PICAXE-Success&highlight=balloon
http://www.picaxeforum.co.uk/showthread.php?16328-Weather-Balloon-Project-20X2&highlight=balloon


e

 

[John West]

Whoever dismissed the PICAXE for EOS (Edge Of Space) balloon flights doesn't know what they're talking about, MFB. All the IC's are still just silicon, and each has its temperature range specified. If a PICAXE is fast enough to do the job required of it over the temperature range expected, that's all there is to it. Altitude tolerance and radiation immunity and such are no more specified for the Ardweenie chips than for the PICAXE.

 

[g6ejd]

Being an avid model aircraft flier, I would choose the PICAXE (and have) any day over my Arduino. Life is too short to write the C code when I can do the same thing in a fraction of the time on a PICAXE and the debugging is easier.

I think there is an element of snobbery in all these factions and whoever is the dominant group or people commands/sets the way forward. One only has to compare the size of an Arduino solution to that of the same in a PICAXE for these applications to realise the advantages of a PICAXE solution!

 

[srnet]

Having successfully used the PICAXE for a number of model aircraft and rocketry projects it seemed logical to continue this approach when starting on a high altitude balloon (HAB) payload. However, on visiting http://ukhas.org.uk/ I was surprised at the dismissive comments about the PICAXE, with the majority of examples being aimed at the Arduino. Following a brief comparison between the two devices it was by no means obvious to me why they should have reached this conclusion.

Personally I find C++ to be rather verbose compared with PICAXE Basic, when for example implementing multiple serial ports with their own time-outs. Yes, Arduino does have lots of support libraries but then its not even possible to implement I2C without one. Unless you need the speed (and most HAB telemetry is only 50bps) or floating point maths, I would have thought the PICAXE was quite adequate for the task ( just look what sernet did with the $50 Satallite!).

Are there any Habbers out there that can provide examples of PICAXE based projects?

Interesting, I had exactly the same reaction about a year back, the HAS guys were very dismissive indeed.

I was treated like some form of idiot, they could not even conceive that a processor running basic could do anything useful.

They even tried to tell me that the RFM22B sending FSK RTTY was limited to around 400km and 50baud because of the high temperature induced drift, but I found a way to avoid the worst of the problem, and its proved to be a brilliant performer, up to 2900km at the higher speed of 100baud. I just came to to conclusion that they had never really tried.

I did a version of the lost model code to go into a ping pong ball, GPS and battery included, data telemetry or FSK RTTY (200baud). Used about half the code space of a 28X2, although most of that was the distance and direction calculation. Ideal basis for a HAB project I would have thought.

 

[srnet]

Altitude tolerance and radiation immunity and such are no more specified for the Ardweenie chips than for the PICAXE.

There are some things to be careful about to do with operating in a vacuum, but radiation does not seem to be a problem at all.

Look at the chassis of $50SAT;

http://www.picaxeforum.co.uk/showthread.php?24846-PICAXE-is-in-Space&p=256001&viewfull=1#post256001

the shielding is only 1/32 aluminum (+ a bit from the solar panels) and one end was completely open, the other covered with a bit of PCB material.

We have yet to detect any RAM or EEPROM corruption, after 10 weeks in orbit.

 

[John West]

Just ask those folks to provide the data comparing their PICAXE and their Arduino flights so you can see where the problems lie. I suspect the silence will be most illuminating.

 

[Dippy]

Well, as usual, it's Horses for Courses. Yes, sometimes one device (or language/compiler) is better than another so sometimes you have to take it on the chin.
Often, two different devices can each happily handle the task.

Srnet and chums have proved the survivability of PICAXE in space - along with careful construction, advice and testing.

Sadly, as in most walks of life, there is a huge degree of snobbishness in the World of Nerd.
In many cases it is simple ignorance (in the true sense of the word) or one-upmanship
It's why some people keep buying the latest iphone when they can't afford it (just kidding).

I work in the electronics field where safety and reliability is tops. The chaps there are brainiacs. But the ignorance about processors (any type) is quite surprising. Usually dyed-in-the-wool old puggers. You know, the usual thing; opinionated 'experts' who have never used one in anger.

And I thought that someone here had already done high altitude stuff with PICAXE (?).

 

[Goeytex]

I looked at the link in the opening posts and it seems the dismissive comments about the Picaxe are the opinions of a few, possibly spearheaded by one.

This is fairly common in the embedded world. When someone becomes experienced and comfortable with a particular platform, they can also become married to it and loose objectivity. They then look for (mostly irrational) reasons not to like and to belittle other platforms, while ignoring the deficiencies in their object of worship. IMO this kind of attitude is childish and unprofessional.

I generally ignore these people and select what works that is within my budget and skill set. It is usually a Picaxe for the simple reason that I am comfortable with the language and the development platform, and it usually meets the requirements. However if I need floating point maths, faster processing, vectored interrupts, or other features not supported by Picaxe, I will happily use another platform rather than try to shoehorn a Picaxe where it doesn't fit.

As far as the ballooning goes, a Picaxe will work fine. Ignore the naysayers.

 

[hippy]

At the proverbial end of the day; suitability comes down to what one wants to do as it goes up, gets there, and comes down again. Every choice will have its advantages and disadvantages. Some things may be easily done on a PICAXE while other things may be difficult or even impossible. The same is probably true for other options.

 

[srnet]

I looked at the link in the opening posts and it seems the dismissive comments about the Picaxe are the opinions of a few, possibly spearheaded by one.
This is fairly common in the embedded world. When someone becomes experienced and comfortable with a particular platform, they can also become married to it and loose objectivity. They then look for (mostly irrational) reasons not to like and to belittle other platforms, while ignoring the deficiencies in their object of worship. IMO this kind of attitude is childish and unprofessional.

This is true.

We did think about using a native PIC and C for $50SAT (the PCBs have the PIC prog header on them) but as the existing PICAXE code did what we wanted, was very well tested and reliable so it would have been a stupid decision to change.

I have been rather distracted of late, but at some point I do intend launching Pongsat just to see how far it will go. The payload is only 20g, PICAXE, GPS, Radio, EEPROM, Battery. Hopefully a budget ballooning enterprise using party balloons.

 

[papaof2]

Unfortunately, the "Mine is different from yours, so it must be better" syndrome can happen during the life of a project.

I dropped out of a project when one of the other (all volunteer) developers got the ARM bug. Of course, he wanted me to drop the PICAXE code (which was working), figure out which ARM chip was the best choice and do all the programming. I got the $4.30 TI430 intro kits (experimenter's board and lessons in PDF and on CD) for the others but there was no interest in even trying the kit. I heard back from him perhaps two years later when he wanted someone to take his new breadboarded design (using two PICAXEs (instead of a PICAXE and a uM-FPU) to a PCB.

I looked at the Diptrace files he sent and asked what his budget was, as the Diptrace files needed much work before a PCB could be made. I never heard back from him - apparently my talents are only of value if they are free.

 

[MFB]

Plenty of evidence here that the PICAXE is adequate for most HAB applications. Although there is some real pioneering HAB development work being done, there are still a lot of projects that only use a GPS tracker that outputs RTTY at 50bps and maybe operate a camera. The PICAXE does lack the Arduino's excellent Tiny GPS library but it still seems to be capable of parsing data. Pity that UKHAB does not make this clearer on it's web site.

 

[Jeremy Harris]

I think there is an element of snobbery in all these factions and whoever is the dominant group or people commands/sets the way forward. One only has to compare the size of an Arduino solution to that of the same in a PICAXE for these applications to realise the advantages of a PICAXE solution!

I wholeheartedly agree.

I made the mistake of using an idea that had been implemented on an Arduino and redesigning it to run using a Picaxe 08M2 (this project: http://www.picaxeforum.co.uk/showthread.php?24286-Photo-Voltaic-Immersion-heater-power-diverter-SAFETY-WARNING! ). As the Open Energy Monitor forum had given me the idea, and as it has the misleading title that includes the term "Open" I stupidly thought that posting details of what I had done there might be thought useful. How wrong I was! It turns out that some folk over there were vociferously anti anything that wasn't based on an Arduino, and decided to give me a hard time over the use of a Picaxe.

I've no doubt that there are a few applications where the Arduino, with it's ability to use floating point math and compile code that runs much faster than Picaxe Basic is useful, by it seems that 90% of the Arduino projects I've looked at used mountains of code to do things that would take a few lines of Picaxe Basic. The gross complexity that surrounds all things Arduino, and the arcane nature of C++, seems to make it rather poorly suited to all the simple control projects that it often seems to get used for.

For high altitude balloon control and telemetry I'd have thought that a Picaxe would be absolutely ideal. There's no need for high speed, no need to handle floating point math and it's desirable that the hardware and firmware be robust, all qualities that the Picaxe and PIC chips in general have in bucket loads. Add in the wide range of supply voltage and low current that a Picaxe will operate at and I would have thought it would suit such a project very well indeed. I wouldn't mind betting that the code development and debug time using a Picaxe would be a lot less, too.

 

[g6ejd]

Yes, those Open-Energy folks are anything but 'open' probably because they are more of a business trying to make money out of Arduino derived boards and PICAXE is competition...

 

[Jeremy Harris]

Yes, those Open-Energy folks are anything but 'open' probably because they are more of a business trying to make money out of Arduino derived boards and PICAXE is competition...

You're right, but I was taken in by their misleading use of the word "Open", implying that they were open to any ideas related to energy monitoring, and the fact that their website uses a ".org" domain, which were originally meant to be for use by non-commercial organisations, I thought. Had they been honest and used a .com or .co.uk domain then I may well have spotted that they were really a business, trying to sell exclusively Arduino related stuff.

 

[John West]

I dropped out of a project when one of the other (all volunteer) developers got the ARM bug.

- papaof2

I had the same thing happen. I described to the interested parties how easy it could be done with a PICAXE. It was a project I offered to see through to the end (for free.) But then someone decided to do it with a raw PIC in assembly, and having no expertise in assembly, I dropped out of the project. I doubt very much if those who were insistent on using something other than a PICAXE ever finished the project. I don't know why some folks are determined to make projects (and life) more difficult than they need to be, but that's often the case.

 

[srnet]

there are still a lot of projects that only use a GPS tracker that outputs RTTY at 50bps and maybe operate a camera

PICAXE does a very good job of 8 bit standard ASCII FSK RTTY at 200baud, you will get plenty of range at that speed, no particular need to slow it down to 50baud.

And whilst UK regs limit the transmissions from a balloon to 10mW, you can boost the output of the humble RFM22B to as much as you need to get real long distance commanding of your balloon. For instance if you want to stop it drifting across the atlantic, send a command to release the balloon and parachute down to earth.

 

[vttom]

90% of the Arduino projects I've looked at used mountains of code to do things that would take a few lines of Picaxe Basic.

Let us not forget the efforts of the fine people at Rev. Ed. who wrote the PIXACE interpretter. They have, effectively, written that mountain of code for us so that our PICAXE BASIC programs can be as small as they are. There's a lot going on behind the scenes of a PICAXE BASIC progam!!

 

[MFB]

Fine people indeed! It was only when I started to learn C++ (due to all the social pressures already mentioned by others) that I really started to appropriate just how well optimized the PICAXE Basic language is for many embedded applications. The whole learning process has also been very well though out by Rev-Ed, with the IDE, simulator and manuals.

I admit to having been seduced by the large number of books about how to use the Arduino but having bought a few it became clear that most are based on a collection of relatively simple project that do not adequately explain the software involved. If you really want to understand what's going on (rather than just cut & paste code) you need to buy a C++ programming book and begin to realize what a steep learning curve your on.

Of course, the reward for all this effort is that you will be able to programme both microcontrollers and high performance computers with the same language. However, for many microcontroller projects that do not need compiler speed and floating point maths, I'm now convinced that C++is an over complex language and should have a warning to that effect printed on the package.

 

[Jeremy Harris]

Let us not forget the efforts of the fine people at Rev. Ed. who wrote the PIXACE interpretter. They have, effectively, written that mountain of code for us so that our PICAXE BASIC programs can be as small as they are. There's a lot going on behind the scenes of a PICAXE BASIC progam!!

That was precisely the point I was making!

There are only two things that, IMHO, could be done to improve Picaxe Basic, and that would be to have the ability to compile the code for better speed (I've had a couple of projects where this would have been really useful) and to have a native floating point math capability. Both have been mentioned here before, though, and I understand there are significant challenges in getting either implemented.

 

[srnet]

That was precisely the point I was making!

There are only two things that, IMHO, could be done to improve Picaxe Basic, and that would be to have the ability to compile the code for better speed (I've had a couple of projects where this would have been really useful) and to have a native floating point math capability. Both have been mentioned here before, though, and I understand there are significant challenges in getting either implemented.

Strange you should mention the compile option, which Rev Ed have said they intend to release. I mentioned that elsewhere, this was the response from a C zealot (offensive comment readacted);

Sounds like they're blowing smoke up people's a****s.

That would completely defeat their economic model of charging for the processors and providing the scripting tools for free.

Sounds like they're trying to pimp the schools into getting them users by teaching them a minority share, oddball system that they'll be stuck using later in life. That's the same thing Apple tried to do here in the US. Millions of kids were forced to learn a 4% market share computing system that never caught on. Many never did learn to use a real computer and you still see them whining online that things aren't available to them on their minority system.

I find the whole thing a very distasteful and shameful strategy.

Maybe they've figured out their strategy will fail in the same way and are going to do what Apple did... steal another system and proprietarize it?

 

[hippy]

Strange you should mention the compile option, which Rev Ed have said they intend to release.

That is still the intention.

With respect to the view that this will utterly destroy our business model so is not to be believed it should be obvious that such issues would have been considered and we do not believe that would be the case.

Undoubtedly some will choose to use our software and not use PICAXE chips but we do not believe this would mean everyone ceasing to use PICAXE chips. We believe PICAXE plays a very useful and important part within education and elsewhere, and it will retain the advantages which make it a preferred choice today; PICAXE and Rev-Ed will continue into the future.

It may well be that some come towards PICAXE, not with the intention of using PICAXE chips, but see that PICAXE offers a better solution than they were heading towards. I got on board with PICAXE, not because I could not choose anything else, but because it offered the best solution for me, and it is even better now than it was back then. There are other PICAXE users who have similar stories.

As to providing PICAXE and software to people, who have a choice to use any tools they choose to use, we would consider providing products and tools to achieve what they want to as a good thing.

 

[MFB]

Almost as important as releasing a compiled version of PICAXE basic would be to port it across to more powerful versions of the PIC family. Such business plans would be very sensitive and there is no point in asking when such new products might be released, is there?

 

[srnet]

With respect to the view that this will utterly destroy our business model so is not to be believed it should be obvious that such issues would have been considered and we do not believe that would be the case.

Its obvious to me too.

I feel sorry for C zealots that hate basic so much they loose the ability to reason properly.

 

[John West]

Hippy's post #23 summed up my own thoughts as well, and I think they have a splendid business model.

I can see from srnet's post #22 how clearly narrow is the thinking of the person he quoted. Does that person truly believe 7 year-old students would be best served by trying to teach them "C" and the internal architecture of micro-controllers, when some of them are still working on getting the right shoe on the right foot?

 

[Jeremy Harris]

My personal view is that I don't think it will harm the business model of Rev Ed at all, in fact it may well make using Picaxe chips more popular, not less popular.

My reasoning is this. The Picaxe system is a very easy way to learn the basics of controlling things, and for education and the vast majority of hobby projects Picaxe Basic is an excellent solution. Those who start off wanting to do real-time stuff fast or need FP math won't be attracted to the Picaxe from the off, they will probably go for something like the Arduino. However, what about those who start off as beginners, get proficient at using Picaxe Basic, but would then like to do things that bit quicker? If there was a compiled version that used the same command set, then there would be a natural progression from the existing Picaxe embedded interpreter to a faster and more capable compiled code microcontroller.

The ability to code and partially debug initially using the existing Picaxe chips, then port the code to a compiled form to get much faster execution speeds towards the end of the development cycle seems a very neat way of doing things. There are plenty of occasions when the slow speed of Picaxe Basic is a positive advantage during development, as it often makes it easier to find out why things aren't doing what you thought they should.

I well remember writing stuff in Fortran 77, sending the code off via a punched tape and teleprinter to be compiled on a mainframe 200 miles away (usually overnight) then getting the object code back the next day with stacks of compile errors. If I'd then had the option of being able to run interpreted source code slowly on a local machine and get most of the bugs out it would have transformed the way I worked!

 

[Dippy]

Yes, paras 2 and 3 make a good case.
That would probably be the USP.
They could easily provide some Include files to set the compiler to initialise the PIC into PICAXEx-alike to make porting easier.
(I avoid using the trendy word 'personality' as it makes me run to the bathroom).

And I'm sure that Rev-Ed are savvy enough to know that they would be competing against some very mature and established compiler producers so they will have sussed the benefits.
I bet they give it a fancy name.
As we know with many BASIC versus C arguments; image means a lot.

 

[Buzby]

I was under the impression that the forthcoming 'assembler' was more of a stepping stone, halfway between interpreted code and real assembler.

This would work like the existing compiler, but instead of generating tokens it would generate a chain of 'lumps' of assembler, each matching a de-tokenised BASIC instruction.
This code would then run in the PICAXE without the overhead of needing to be de-tokenised and interpreted.

This would run faster than a normal PICAXE, but nowhere near as fast as optimised assembler.

Rev-Ed's propriety software will still protected, because the user can't write 'real' assembler, and I think it's mentioned somewhere that using the PICAXE 'assembler' will prevent the use of the 'normal' PICAXE interpreter ever again on that chip.

Either way I think it's a good option, but not one that should be too easy for a beginner to switch on accidentally.

If the user needs real speed, and floating point, and strings, etc... then there are 'real' BASIC compilers for the PIC family, most of which are just a few steps up the learning curve than PICAXE. No need to even mention C, or Arduino.

 

[Goeytex]

Sound like this might be turning into an Anti-C / Anti-Arduino rant, with some comments not too far removed from what I saw on the Open Energy site in regards to Picaxe. Be careful not to lose objectivity concerning other platforms and other programming languages. As the saying goes, it's horses for courses.

Try to get a job in the embedded systems world with your only programming experience being with Picaxe Basic.

 

[Buzby]

Sound like this might be turning into an Anti-C / Anti-Arduino rant, ...

I did not mean it to come out like that.

My day job is programming, but I don't use C or BASIC, I use the IEC 61131-3 languages, so I've no axe to grind one way or the other.

Using these languages has exposed me to just the same sort of arguments as the C vs BASIC, PICAXE vs ARDUINO, Windows vs Linux, arguments going on all the time.

IEC 61131-3 is a set of widely different languages, but they all run on the same target system, and can all be used simultaneously. ( Imagine a PICAXE that could run BASIC, C, and FORTRAN, all at the same time !. )

Even in this environment you will find engineers who decry one 61131 language or another, and will say that their favourite IEC language is the best and only way to program.

They miss the point that the language to choose is whichever is best suited to the specific problem. The language you might use to drive a set of airport landing lights will be different to the language used to read the database that sets the light patterns.

So I'm sorry if I came over anti-C or anti-Arduino, I'm really just anti-discriminatory.

 

[Graham O]

Only just found this thread as I get back into using Picaxes. It is certainly possible to use a Picaxe for a HAB flight computer. I built one with a 20X2 which reads the GPS, extracts relevant data, reads sensors, adds some other bits of data, constructs the transmit sentence, generates the CRC sum and then transmits the data. I found there was some suggestions that an arduino would be better, but it was never defined what "better" meant. Add in the fact that I don't know C and the Picaxe was the logical choice.

 

[srnet]

I have been looking at this myself recently, I want to build a party balloon type HAB, that can take pictures onto a Micro SD card. It needs to be light, 25g or so, which ought to be possible.

Most of the code is already done and working for 28X2, GPS parsing, RTTY transmission, remote command ability (balloon release as I want it back) etc, it works and I see no particular reason to use anything else. I think there is scope for a PICAXE product here, the code in PICAXE form should be easy for the masses to understand and change, and with party balloon type HABs cheap to build and launch, could be popular.

UKHAS do have a very effective tracking system for HABs using FSK RTTY and a modified version of FLDIGI, a lot of receivers\stations tune in and co-operate, the downloaded RTTY gets sent to a central server to be mapped onto a Internet accessible tracking page.

However its possible to track a HAB in a much simpler way, although maybe not as far. The humble RFM22B when run at 10mW (UK limit) will transmit data packets that you can receive with a handheld yagi at about 40km, add a low noise amp and you should able to track at 120km or so. I simplified my PICAXE handheld tracker recently, see picture. Press a button on the receiver and it stores the last received GPS location from the remote transmitter. Keep the button pressed and it tells you how far away and it what direction the transmitter is.

I have found the UKHAS guys are a bit more receptive these days, even when I own up to using a PICAXE, but then its been proven that a PICAXE can survive in a pretty hostile environment and they have even asked me to do a presentation on $50SAT.

 

[MFB]

Good to hear that UKHAS is becoming more responsive to the PICAXE. I had feared they were heading too far in the opposite direction, by starting to use the high current demanding Raspberry Pi.

The zero-pressure pico balloons offer the potential for long duration flights (B41 for example was recently launched from Silverstone and reached the Turkish border via Russia) but have very limited payload capacity. I would have thought this was a perfect application for a low power/pin count PICAXE. So good luck with your $50 satellite presentation to UKHAS?

 

[srnet]

Dunno if I would call it responsive, but no longer can it be dismissed out of hand.

There is a fair bit of popularity with the Pi for HAB, but its a how many sherpas do you need to carry the food for the sherpas situation.

A Pi is power hungry, which means big battery, which means big heavy balloon filed with lots of (expensive) helium.

The B41 is an example of a very light payload, very power efficient, means small battery, and thus very small and cheap balloon.

There was the HIPI that ended up in the Atlantic off Ireland, nice pictures apparently, but why they dont use a command uplink with the RFM22 to release the balloon so you can get it back ? As long as the balloon is above the radio horizon, an RFM22 amplified up to a modest 20W will allow control at around the 1500km mark.

I would have thought this was a perfect application for a low power/pin count PICAXE.

Ideal application really ........

Good idea for school science projects and very affordable.

I was amused by the problem the 6 pin program header caused for the B41 guy, so he made it as a snap off part of the PCB, once programed and tested the header was snapped off. Now a 'program header' for a PICAXE can be left permanently connected, you only need to have some PTH holes in the edge of the PCB.

 

[MFB]

The reason that 433MHz uplinks are not used probably relates to legal issues. Ofcom may not allow this frequency to be used for 'radio control' of an airborne object. What is more puzzling is the choice of single side-band RTTY as the UKHAB telemetry 'standard' when the use of AFSK RTTY would allow balloon telemetry to be received by low cost Chinese equipment (as proven by the $50 Sat). The reason often given is the SSB is more power efficient. However, in contrast to pico types, most small latex balloon flights seem to be of only a few hours duration and therefore operate over slant ranges that rarely exceed hundreds of miles. Of course there are exceptions, like trans-Atlantic floaters, but they tend not to be restricted to 10mW at 433Mhz. Maybe its time to be as open minded about telemetry modes as it is about microcontroller options.

 

[srnet]

The reason that 433MHz uplinks are not used probably relates to legal issues. Ofcom may not allow this frequency to be used for 'radio control' of an airborne object.

Ah yes, I was in RC thinking mode where anything goes.

However with something like an RFM22 its very simple to flip the airborne device between one frequency for TX (limited to 10mW) and another for RX.

So as a minimum you can use the 468Mhz RC band at 100mW, which ought to get you at least 40kM command range.

What is more puzzling is the choice of single side-band RTTY as the UKHAB telemetry 'standard' when the use of AFSK RTTY would allow balloon telemetry to be received by low cost Chinese equipment (as proven by the $50 Sat).

Possibly due to the popularity of the very cheap RFM22, where FSK RTTY is easy to generate. However even a few 10s of hertz of frequency drift can cause a problem, which you dont get with AFSK in FM mode.

The RFM22 can be persuaded to do AFSK RTTY, but its about 10dB behind the FSK RTTY. However you should still be able to manage around 50km plus at 10mW which is enough for a lot of stuff, and as you say you could use cheap Chinese HTs to receive it. No reason why you cant just alternate the tracking transmissions, data telemetry, FSK RTTY, AFSK RTTY as you dont need to send position updates all the time.

I have attached a spreadsheet which shows the relative effectiveness in dB of the various modes the RFM22 was capable of. Its based on reducing power tests at a range of 4kM, I noted the power level at which messages were corrupted.

Maybe its time to be as open minded about telemetry modes as it is about microcontroller options

Yep.

 

[Graham O]

IIRC, the reason for choosing FSK RTTY was due to communications efficiency, km per mW, ease and cheapness of generation and the small number of receivers in the early days. With not many people listening, you would want the most reliable comms you could get in order to recover the payload. There was also no requirement for two way comms, so the simplest TX method was, and still is, effective. There are no rules in HAB'ing, so if you want to use a different modulation mode, by all means go ahead, but there may not be many people listening and if it goes out of your range .........

Reception on cheap FM portables has largely been negated by the even cheaper SDR TV dongles which allow almost any mode of operation, so even the limited listeners argument is no longer as valid.

When signals are strong, the difference between AFSK and FSK is largely irrelevant, but it is at low signal strengths that FSK will win. With AFSK, you will lose the signal earlier than you will with FSK. Now that may not be a problem, it all depends on what your needs are. If you are planning a straight up and down flight, without much drift, then it's not a problem, but for longer drifting flights, you want to be able to track it for longer, so FSK wins.

A lot of this is like the Picaxe vs Arduino arguements. People confuse efficiency with effectiveness. The Picaxe is not as fast as an Arduino, doesn't have the user base, doesn't have the range of libraries, doesn't use C, therefore, to some people, the Picaxe is not as a good as the Arduino. But if you don't need these things, then they are irrelevant. If the task can be accomplished by both controllers, then they are equally effective and there is no difference between them.

For myself, I've recently gone over to the Dark Side and bought a couple of Arduinos. I'll use them for what they are good at, but I'll stick to Picaxes for the serious work

 

[MFB]

Yet again I'm amazed at the depth and clarity of information provide on this forum. Many thanks srnet and Graham O.

 

[srnet]

The king of the minimalist approach to tracking a balloon or similar, it to get it to transmit distance and direction from home as slow Morse numbers, easy enough and FM Morse as those who have listened to $50SAT will know goes a very long way indeed.

FSK Morse also easy to transmit, but although harder to receive will still be clearly head at the point where FM Morse is inaudible, and has about 3 times the range.

All you need then is a map and compass as you harry around the contryside chasing your balloon.