PICAXE is in Space
- Thread starter srnet
- Start date
If you want to hear the story of one of the other 3 PocketQubes that were launched, this video is about T-LogoQube (Eagle1)
https://www.youtube.com/watch?v=uGzuLB2mrt0
T-LogoQube stopped responding late January, the other two PocketQubes did not appear to work either.
I am trying to get information on ground station setup for T-LogoQube, they were using a RFM22B in their satellite also, but with with a tracking array of two crossed 18dB yagis. They were getting packet data back from 2700km, that's close to horizon to horizon coverage, not bad for a $5 radio module.
https://www.youtube.com/watch?v=uGzuLB2mrt0
T-LogoQube stopped responding late January, the other two PocketQubes did not appear to work either.
I am trying to get information on ground station setup for T-LogoQube, they were using a RFM22B in their satellite also, but with with a tracking array of two crossed 18dB yagis. They were getting packet data back from 2700km, that's close to horizon to horizon coverage, not bad for a $5 radio module.
I have been able to listen to most of an Eagle 2 transmission (using a Moxon antenna with a Baofeng UV-5re receiver) but only on those rare occasions when the pass is pretty much right over the top. This is probable because the receiver is left fixed to 437.505MHz. Please could someone advice on the best tuning technique to accommodate the Doppler shift?
The signal does vary by as much as plus 10khz as its approaching and minus 10khz as its going away.
Most of the change happens in the few minutes around closest approach. Approx two minutes before closest approach it will be at +9khz and at two minutes after about minus 9khz.
Specifically for the UK, $50SAT is still very cold as its not been long out of eclipse, and its running about 2khz high.
I generally start at about 437.515Mhz, and wind it down in 2.5khz steps as it gets close, the Baofeng will do 2.5khz steps I believe..
However you wont miss it if the radio is 5khz out, they are just not selective enough.
Most of the change happens in the few minutes around closest approach. Approx two minutes before closest approach it will be at +9khz and at two minutes after about minus 9khz.
Specifically for the UK, $50SAT is still very cold as its not been long out of eclipse, and its running about 2khz high.
I generally start at about 437.515Mhz, and wind it down in 2.5khz steps as it gets close, the Baofeng will do 2.5khz steps I believe..
However you wont miss it if the radio is 5khz out, they are just not selective enough.
Yep, around that time tonight.
This morning I left my RFM22 PICAXE receiver on, using the 70cm VLNA with a £10 DIY QF helix omnidirectional antenna.
When I got back home, it had received telemetry packets;
PktType,34,Len,24,RSSI,156
InfoPkt,RXContents,128,0,0,196,2,0,0,0,58,3,0,21,134,81,0,122,0,34,2,18,14,227,0,7
Flags,TXNocharge
Distance to $50SAT, 620km or so.
In the news again;
http://www.nature.com/news/mini-satellites-prove-their-scientific-power-1.15051
Smaller still
Leaders in the field are now pushing for a smaller standard size. In 2009, Twiggs slimmed a CubeSat down into a 5-cm-a-side ‘PocketQube’; the first four launched in November 2013. One of these demonstration projects, jokingly named $50SAT, cost just a few hundred dollars in parts — including a $14 chip for a two-way radio. “I love the idea that I can basically get something at Walmart and fly it in a satellite,” says Twiggs.
http://www.nature.com/news/mini-satellites-prove-their-scientific-power-1.15051
Smaller still
Leaders in the field are now pushing for a smaller standard size. In 2009, Twiggs slimmed a CubeSat down into a 5-cm-a-side ‘PocketQube’; the first four launched in November 2013. One of these demonstration projects, jokingly named $50SAT, cost just a few hundred dollars in parts — including a $14 chip for a two-way radio. “I love the idea that I can basically get something at Walmart and fly it in a satellite,” says Twiggs.
srnet, I was reading an article about the watchdog timers I was interested to learn about soft errors caused by cosmic rays. It seems that SRAM is particularly prone to such errors and Flash to a lessor extent. During your development of the $50 Sat, did you find any information references to the effect of cosmic rays on microcontrollers? Most of the references that I have managed to find refer to microprocessors with external DRAM.
What an opertune question.
One of the issues with the development of $50SAT was the lack of real information available on the effects of radiation especially on commercial parts, and by lack I mean virtually none, but maybe we did not look hard enough.
Also previous projects (on Cubesats) seem to publish very little data about problems encountered or performance, again maybe we just did not look hard enough.
So $50SAT was a venture into the unknown, especially as far as the PICAXE is concerned, although its possible native PICs have been into orbit.
However, I did add some features to the $50SAT code that has allowed us to monitor for some adverse radiation effects, and bear in mind that the PICAXE on $50SAT has the benefit of only 1/32” aluminum shielding on 4 sides and no shielding on the other two.
At every beacon loop, so about 40 times an hour on average, a 512byte block of scratchpad RAM is checked for corruption, it’s a sequence of $55 and $AA bytes.
At every beacon loop the RFM22B (radio) is setup from an area of table about 64 bytes long. The program knows what the checksum should be, an error detected is reported. At the same time a matching set of data stored in EEPROM is also checked for errors and reported.
I said it was an opportune question as Michael (in the US) has just updated the reception reports for the last few weeks. The picture is the same, to date there have been NO corruptions spotted of RAM, FLASH or EEPROM, so if there is a problem with radiation its not a big one.
Due to an error with the way resets (of the PICAXE) are recorded in $50SAT, I can’t be certain there have been no program crashes or latch ups (causing an over current issue). However, the program does force a processor reset every 250 beacon loops, about every 5 hours. Plotting the count of resets (recorded in EEPROM and sent out in the data) over time shows a fairly straight line, which is consistent with the only resets coming from the regular program resets.
One of the issues with the development of $50SAT was the lack of real information available on the effects of radiation especially on commercial parts, and by lack I mean virtually none, but maybe we did not look hard enough.
Also previous projects (on Cubesats) seem to publish very little data about problems encountered or performance, again maybe we just did not look hard enough.
So $50SAT was a venture into the unknown, especially as far as the PICAXE is concerned, although its possible native PICs have been into orbit.
However, I did add some features to the $50SAT code that has allowed us to monitor for some adverse radiation effects, and bear in mind that the PICAXE on $50SAT has the benefit of only 1/32” aluminum shielding on 4 sides and no shielding on the other two.
At every beacon loop, so about 40 times an hour on average, a 512byte block of scratchpad RAM is checked for corruption, it’s a sequence of $55 and $AA bytes.
At every beacon loop the RFM22B (radio) is setup from an area of table about 64 bytes long. The program knows what the checksum should be, an error detected is reported. At the same time a matching set of data stored in EEPROM is also checked for errors and reported.
I said it was an opportune question as Michael (in the US) has just updated the reception reports for the last few weeks. The picture is the same, to date there have been NO corruptions spotted of RAM, FLASH or EEPROM, so if there is a problem with radiation its not a big one.
Due to an error with the way resets (of the PICAXE) are recorded in $50SAT, I can’t be certain there have been no program crashes or latch ups (causing an over current issue). However, the program does force a processor reset every 250 beacon loops, about every 5 hours. Plotting the count of resets (recorded in EEPROM and sent out in the data) over time shows a fairly straight line, which is consistent with the only resets coming from the regular program resets.
I did try initially without a lot of success.
Professor Twiggs was also unaware of any real data published on the subject from the various satellite projects he had been involved in.
I also tried since to communicate (on a technical issues) with two of the other PocketQube teams, with little success either.
For anyone interested, it might be worth checking out the Funcube project, on the same launch as $50SAT, the are (unusually) being very public with the the data they are collecting, maybe they have information on radiation effects on the electronics.
Thanks for the feedback. IBM found in the 90's that a typical ground level computer experiences about one error due to cosmic rays every month per 256MB of RAM. This can only have become worse with advances in fabrication density and would of course increase with altitude. Cosmic ray flux peaks at about 15km in altitude and then drops sharply. I have therefore decided to use an external watchdog reset circuit on my balloon payload, as even internal microcontroller watchdog registers and non-makable interrupt routines might be prone to soft errors.
It might be worth trawling Google for specs and datasheets of radiation hardened micros as they may well have specifications of what they stand up to which could give an indication of what likelihood and type of events there are. Not sure if any of these are useful but would be the sort of thing I'd search for -
microelectronics.esa.int/components/80S32-RadiationReport-v1.3.pdf
books.google.co.uk/books?isbn=140205646X
ftp://128.196.250.12/pub/pub/cubesat/cubesat_papers/controller.pdf‎
microelectronics.esa.int/components/80S32-RadiationReport-v1.3.pdf
books.google.co.uk/books?isbn=140205646X
ftp://128.196.250.12/pub/pub/cubesat/cubesat_papers/controller.pdf‎
Wise decision.
$50SAT used the MAX6369, not the easiest device to solder and not particularly cheap, but it does the job, can be configured for up to around a 1-2min watchdog period which is ideal for a micro that can spend a while in low power sleep mode.
I will setup the PCB on on the tracker I am working on, for Pico party balloon HABs, to take one. Then you have the choice of fitting it or not, no mods needed to circuit or code.
I decided on the MAX 6301 because it the watchdog and reset times can be independently set by two capacitors. In extended mode the time-out period can be over 1000 seconds.
Its interesting that your thinking about foil super-pressure (e.g. party) balloons as the UK HAB community have recently achieved some impressively long durations flights. One launched from Silverstone reached Pakistan after a flight of several days. Given the duration and typical altitude (10km) of these flights it would be interesting to see the results of the type of memory error tests that you developed for the $50 SAT.
Its interesting that your thinking about foil super-pressure (e.g. party) balloons as the UK HAB community have recently achieved some impressively long durations flights. One launched from Silverstone reached Pakistan after a flight of several days. Given the duration and typical altitude (10km) of these flights it would be interesting to see the results of the type of memory error tests that you developed for the $50 SAT.
What would be real good is a follow up which reports what actually happens in practice, i.e. what exactly is the recorded occurrence of radiation related issues ?
One thing is clear is that a lot of Cubesats (and even PocketQubes!) fail to meet objectives;
http://www.jossonline.com/downloads/0202 The First One Hundred Cubesats.pdf
What a fascinating paper! As so often, planning and system testing are key weaknesses. So many fail to fly successfully as planned that after a successful launch and initial functioning the odds of a failure due to cosmic radiation are rather irrelevant.
Though I do wonder how one might arrange memory washing in a microcontroller with firmware already loaded, without error-correcting bits and additional control hardware.
Though I do wonder how one might arrange memory washing in a microcontroller with firmware already loaded, without error-correcting bits and additional control hardware.
Yes, the Pico balloons have been going a long way, I am sure there will be a lot more activity in that part of HABing in future.
There is obviously merit in large payloads as there is in larger satellites (Cubesats!), but not quite my thing, I don’t see myself paying £50-£100 for a latex balloon and carting a large heavy cylinder of hydrogen about to fill it. I have concerns about large blocks of polystyrene falling out of the sky at random too.
Pico balloons using either normal latex party balloons or the foil ones are much more appealing to me, no need for CAA approval, and you should be able to do the tracking yourself. Even at the UK limit of 10mW, with a Yagi and LNA the telemetry from a RFM22B ought to get you 150kM or so, assuming the balloon is within the radio horizon, the FSK RTTY good for a great deal further.
Most of the Pico stuff seems to be Arduino based, but I already have most of the code done for a tracker in PICAXE, so it seems daft to start again with Arduino. Not sure I have seen any of the Pico tracker code as open source.
A Pico tracker in PICAXE, under 25g ought to be possible, I found a nice flash RAM for the tracker storage;
http://www.picaxeforum.co.uk/showthread.php?25837-High-Altitude-Balloon-Tracker-and-using-the-SST25VF032B-4Mbyte-Flash-memory
That thread shows its possible (just) to mix SPI and I2C on the same PICAXE, so you don’t have to shut the door on future additions or expansion.
One helpful improvement to the 28X2 and 40X2 firmware would be to allow the second SPI\I2C port to be used directly …………………..
There is obviously merit in large payloads as there is in larger satellites (Cubesats!), but not quite my thing, I don’t see myself paying £50-£100 for a latex balloon and carting a large heavy cylinder of hydrogen about to fill it. I have concerns about large blocks of polystyrene falling out of the sky at random too.
Pico balloons using either normal latex party balloons or the foil ones are much more appealing to me, no need for CAA approval, and you should be able to do the tracking yourself. Even at the UK limit of 10mW, with a Yagi and LNA the telemetry from a RFM22B ought to get you 150kM or so, assuming the balloon is within the radio horizon, the FSK RTTY good for a great deal further.
Most of the Pico stuff seems to be Arduino based, but I already have most of the code done for a tracker in PICAXE, so it seems daft to start again with Arduino. Not sure I have seen any of the Pico tracker code as open source.
A Pico tracker in PICAXE, under 25g ought to be possible, I found a nice flash RAM for the tracker storage;
http://www.picaxeforum.co.uk/showthread.php?25837-High-Altitude-Balloon-Tracker-and-using-the-SST25VF032B-4Mbyte-Flash-memory
That thread shows its possible (just) to mix SPI and I2C on the same PICAXE, so you don’t have to shut the door on future additions or expansion.
One helpful improvement to the 28X2 and 40X2 firmware would be to allow the second SPI\I2C port to be used directly …………………..
sernet, I'm pleased to hear you will be applying your satellite expertise to pico balloon projects. Much cheaper and easer/safer to fly than larger latex balloons. As you said, this hobby is currently dominated by the Arduino, but I would have thought now ripe for the introduction of the smaller members of the PICAXE family. I surprised you have not found much open source Arduino code for GPS trackers. Here is just one of many examples...https://github.com/jamescoxon/PicoAtlas/blob/master/Pico6MK3/sketch_apr02b/sketch_apr02b.ino
Some use quite exotic coding techniques to achieve maximum range with 10mW transmitters and are compatible with the global HAB tracking network. That how the very long distance pico flights are tracked over thousands of Km. I now see the main challenge as how to do some useful science using these platforms. My experiments are currently restricted to the higher lifting-capacity latex types.
Some use quite exotic coding techniques to achieve maximum range with 10mW transmitters and are compatible with the global HAB tracking network. That how the very long distance pico flights are tracked over thousands of Km. I now see the main challenge as how to do some useful science using these platforms. My experiments are currently restricted to the higher lifting-capacity latex types.
Anyone interested in the progress of recent and ongoing pico balloon flights can track them at http://spacenear.us/tracker/
I don't know if firmware and compilers would be updated to support that but both SPI and I2C protocols can be reasonably easily bit-banged and it may be possible to gain access to the on-chip hardware through accessing SFR. I expect it would be easier to access and use the second SPI channel if it is possible.
For a comparison of the methods of providing an alternative SPI on an X2 PICAXE see here;
http://www.picaxeforum.co.uk/showthread.php?25837-High-Altitude-Balloon-Tracker-and-using-the-SST25VF032B-4Mbyte-Flash-memory
Bit bang SPI works, but is too slow to be used to drive a radio in a tracker and only just acceptable for writing to a flash memory.
Not so sure about that, I would be starting with a 28X2, possibly a 40X2, so as not to close the door on needing extras I\O in the future.
The radio of choice for me would be the RFM22, cheap, frequency agile and programmable for low power. That radio needs an SPI interface, so it would only be useable on an M2 if the PeekSFR\PokeSFR approach I described in the Flash RAM thread works on the M2, I have not tried it.
I heard one HAB using Thor, but I thought the balloons tracking outside of the UK was mainly APRS ?
My idea would be to do an initial basic PCB around 100mm x 25mm, with GPS, Radio, Temperature and pressure sensor, Flash RAM, Watchdog and power cut hardware all run from a single Lipo. Then provide some 0.1" holes\pads on the long edge for adding stuff like cameras (small ones!), voltage up converters for a single AAA\AA and of course experiments.
My next task is to patch a PICAXE into one of the SMT UBLOX GPSs, just to check that I have the wiring right.
Maybe I should start a separate thread for the project .............
That new thread sounds very interesting. I'm pretty sure that the recent pico flights B45 and B46 relied solely on 433 MHz at 10mW for tracking to Asia. It also seems that any data encoding standard, that can be decoded by the PC based dlFigi decoding software, is used by the UK HAB community for tracking and telemetry. Lots of information on the 'standard' telemetry format is available on the UKHAB wiki.
Has that now become UKHAS or is that something else ...
[PLAIN]http://ukhas.org.uk/communication:protocol[/PLAIN]
Thats the output format, and the $50SAT code supports that already, although the HAB guys do prefer a CCIT 16 Checksum.
The encoding used by pico flights B45 and B46 was 'Contestia 8/1000' which without a significant mod, the RFM22 is not going to be able to do, and the PICAXE may not be fast enough to do anyway.
The FSK RTTY, which the RFM22 does rather well, provides plenty of range for most uses ......
Sorry, just a typo. Should of course have been 'UKHAS'. If we do want to encourage PICAXE users interest in starting pico balloon projects, then the $50SAT communications approach would definable be a good starting point. As the likes of Contestia 8/1000 does involve probably unnecessary complex code.
srnet, it would be really great if you could find the time to develop a reference design for a pico balloon tracker. Avoiding the need to use the Arduino should really help get things moving.
srnet, it would be really great if you could find the time to develop a reference design for a pico balloon tracker. Avoiding the need to use the Arduino should really help get things moving.
Just thought that another advantage of the $50SAT communications approach would the ability to receive data using low cost rf receivers, that do not normally support the SSB mode normally used by UKHAS flights. However, no reason why $50SAT communications technology would not be compatible with the existing international tracking network at a lower entry cost.