PICAXE in Space

hippy

Technical Support
Staff member
Anyone know of a RTTY application that will display the hex value of decoded characters ?
PICAXE decoding, converting to hex, then sending at a standard PC baud rate and any terminal emulator should do ?
 

hippy

Technical Support
Staff member
How does a PICAXE decode transmitted AFSK RTTY ?
No idea. I'd assumed there's some 'magic box' that takes the signal in, converts it to a high/low or ideally a 45 or 100 baud digital serial signal.
 

MFB

Senior Member
PC sound cards are now pretty much the standard for decoding AFSK with a choice of free software for radio HAM operators, that is also able to decode RTTY.
 

srnet

Senior Member
PC sound cards are now pretty much the standard for decoding AFSK with a choice of free software for radio HAM operators, that is also able to decode RTTY.
So do you know a decoder which displays the hex value of the decoded byte ?
 

srnet

Senior Member
No, but there probably is one.
Yet to find one though.

I have been experimenting sending the data packet, around 20 bytes, as hex characters with 120WPM Morse, with some sync characters this takes about 7 seconds. FLDIGI decodes this fine, even on a low powered netbook.

Looks like the Morse has about a 3dB signal advantage over the RTTY, although I will be doing some long range tests to confirm this.
 

srnet

Senior Member
Some info for Morse skeptics;

As part of the testing for this project I had tested the line of sight range of the data telemetry between distant hilltops, the 100mW that the RFM22 can transmit was enough for reliable reception of packets at 40km.

At the time I made some recordings of the Morse audio also produced by the beacon, and have just been evaluating the results.

The recording of the beacon transmission, 40kM away was made with a FT60 with a 1/4 whip, with at each successive loop of the beacon software the power reducing. This made it easy to work out the limits of reception. The attached ZIP file contains a MP3 recording of the distant beacon at 12.5mW, 6.25mW, 3.2mW and 1.6mW. The last is very feint.

The FLDIGI software (free) running on a low spec PC Netbook will decode the 15WPM Morse down to 3.2mW, and 60WPM down to 6.25mW, which in approximate terms gives the faster Morse data a distance advantage of 4 times that of the RFM22 data telemetry, if Morse and data were running at the same power.

This should equate to a LOS distance for the fast Morse of circa 160kM at the full 100mW.

I have since been experimenting with running the Morse at 120WPM and it seems to perform much the same as 60WPM, a slight degradation is noticed at 150WPM.

Hope have recently released a 1W version of their transceiver, that should give a LOS range of data telemtry of approx 125kM, and Morse data LOS of 500kM, awesome.

I have also just had the satellite board tested in a chamber from -40C to +70C. It worked. I have some recordings of the beacon audio so I will be able to work out the change in the frequency of the internal clock, results later.
 

Attachments

Dippy

Moderator
That looks great srnet.
When is launch?

Just out of interest; are there regs on RF power, frequencies, Tx spec, bandwidth, duty and all that sort of stuff?
I take it your box will be next to many other little boxes all peeping away?
 

srnet

Senior Member
That looks great srnet. When is launch?
Latest we have heard is January, some issue to do with moving the rocket to another Silo.

Just out of interest; are there regs on RF power, frequencies, Tx spec, bandwidth, duty and all that sort of stuff?
Sure. Its under the IARU rules and satellite frequency coordination, we have an allocated frequency and need to follow normal Amateur radio rules, with regards to transmission of callsigns (mine in this case).

Do not know what the max power rules are, we are using way way less power than is normal, and 100mW is a real challenge when you need a range of 1000km plus.

Fortunately the RFM22 as a receiver has proved to be sensitive enough to allow the groundstation uplink to work, there is a regulatory requirement to turn off the transmitter if required, as is the case for normal amateur radio transmissions. The link budget suggests that amplifying the RFM22 output (on the ground) up to about 35W and using a modest yagi, should allow control of the satellite pretty much out to the radio horizon. Proving this is why I have spent so much time running around with transmitters on mountains.

I take it your box will be next to many other little boxes all peeping away?
There are a few out there now. This will be the smallest ever, and the cheapest by a very large margin. Its been nicknamed $50SAT, because that is about how much the electronics have cost.

Its an educational project by Morehead State University in the US. The students there are also building a PICAXE\RFM22 based satellite, and the 3 of us building $50SAT (me and two amateur radio guys in the US) have been sharing code and designs with the students in the US.

I did think of making it transmit 'PICAXE' in Morse, but I guess that might fall foul of commercial advertising rules ......
 

Paix

Senior Member
Hello Snet, Copied the "012" OK (of course), the fourth iteration I didn't copy the "0" as it was lost in the noise, but copied the "12" component. Nice to have some essential info at manual speed as it allows less specialist receive operators around the world to copy and forward details should you need them.

Often odd behaviour seems to be more apparent away from home :)
I would have put money on the RTTY being more readable (at the same speed) than 60wpm or 120wpm.

I well remember checking TAFORS morse tapes prior to putting it on a MATELO broadcast many years ago. The broadcast was at 18wpm (max speed for such broadcasts) and checking it at 50wpm with the hard copy in front of me. I can tell you that contact was tenuous and had to rerun any errors at 30wpm to detect which character was actually wrong (usually a feed rake problem in the perforator).

Impressive. I bet the frequency coordination was a long drawn out process. Don't forget to let us know the designators so that we can get the TLE data from space-track.org after being allocated a tracking identity (NORAD #) and AO(?) name. Some of us can then listen for any manual speed (<20wpm) Morse components in your transmissions.

What is the significance of the "012" in the test transmissions?

Will the satellites have a web site up pre-launch to advertise the upcoming event? It made the Delfi-C3 very visible to the amateur radio community and payed dividends for the project as far as I can tell. http://www.delfispace.nl/index.php/participation/radio-amateur-participation

Launch your project and promote your birds!
 
Last edited:

srnet

Senior Member
Nice to have some essential info at manual speed as it allows less specialist receive operators around the world to copy and forward details should you need them.
There wont be any data sent out at 15WPM, uses two much power, just think of how many solar panels you can get on a 50mm cube ........

However, and I have tested this, you can record the incoming fast Morse audio to a PC, shift the pitch and play it back at more normal human speed.


I would have put money on the RTTY being more readable (at the same speed) than 60wpm or 120wpm.
That would be classical thinking, yes. But the radio cant do proper AFSK RTTY, its digital only. It can manage square wave FM tones, and then the Morse has around a 3dB benefit as far as the FLDIGI decoding software is concerned. FSK RTTY is kinda difficult due to doppler issues, the satellite will be moving at circa 27,000kmph after all.

I bet the frequency coordination was a long drawn out process.
I guess so, but it was Professor Bob Twiggs who sorted all that out, I was just asked that if I could come up with a working design for the form factor, it would be launched.

What is the significance of the "012" in the test transmissions?
Laziness, apart from my call sign going out every so often, I cut the beacon loop as short as possible whilst using the flight software. I can read Morse numbers but not much else, and I cut it down to 3 characters.

Incidently, its the Morse beacon at 15WPM that uses the vast majority of the power, it will be sent out (sunlight permitting) every 30 seconds or so.

Will the satellites have a web site up pre-launch to advertise the upcoming event?
Very likely. I registered the web site name (£2) just in case;

http://www.50dollarsat.info/

So you never know.
 

Paix

Senior Member
Thanks for the update, I will look again at your £2 worth nearer and after the time.

I had missed the fact that the tranceiver doesn't do pukka AFSK. Interestingly from the Delfi-C3 has the RASCAL software (Java, so OS agnostic) to demodulate and decode the received telemetry and the SATCOM C4 satellite recommended commercial MixW demodulating software, making it a Windows only feast and it wasn't free. there is now a lot of free software to demod standard RTTY signals from space, but as you say Doppler and AFSK/FSK make life interesting. The demodulator needs to have a degree of AFC to look after small errors, while the radio has to tune up to plus and minus 6kHz (a bit like the proverbial ducks feet under the water) to keep things in any form of kilter.

All the Doppler correction has to be done at the ground station of course and doubtless becomes more interesting when trying to issue uplinked commands which are a little more critical than losing a packet or two of telemetry reception. :)

I have a couple of windscreen wiper motors that are destined for duty in an AZ-EL rotator. Bad news, they have been destined for a few years now! Familiar story.

I'll shut up now and read with interest.
Ian
 

srnet

Senior Member
For the data Uplink it looks like we wont have to worry about doppler much. At the receiving end, I have already tried offsetting the RX frequency by 10khz, and the AFC of the RFM22 brings the packet in with little loss of signal reliability, though it does start to suffer a bit at 15khz. When the satellite receives a valid data packet it responds by sending the RSSI and packet type as slow Morse, so even if the data down link wont work we will know if the uplink is. If we had to track the frequency of the RFM22, it would be easy in any case. The listen period is right after the slow Morse beacon, so the incoming frequency shift can be seen. Two buttons and the ground station PCB and the receiving frequency can be easily shifted up or down.

A UHF transceiver, yagi, a PC running FLDIGI, is we hope all the kit that is needed to receive the fast Morse on the ground and adding a DIY low noise amp kit should help too.

I have tried putting a LNA in front of the RFM22, but it does not help, its input stages are just swamped by the wide band output of the LNA, so I have a mini circuits bandpass filter coming from the US to try, and some SAW filters off eBay.

Its a shame that the 1watt version of the RFM22 was not available 6 months ago, the extra 10dB for the data downlink budget would help a lot, next time maybe.

I know a lot of this sounds almost crude, but the idea has been to try and come up with simple workable solutions that a school or college would be able to replicate, so low cost, low complexity is the order of the day.

As a fallback, and since this is an educational project being run by Morehead University, the students should be able to nick some time on their 21M satellite tracking dish, picture 2 in the moving sequence here;

http://www.moreheadstate.edu/ssc/
 

Dippy

Moderator
That sounds juicy stuff. Well done old chap.

I wonder what the Doppler effect will be?
I guess if you can get the true velocities involved and do some trig you can work it out roughly.
Obv it would vary with position.
Maybe someone has already done it?
 

srnet

Senior Member
The guys over at Morehead, are well experienced at small satellites, they just launched this;

http://www.moreheadstate.edu/News/2012/October/First_contact_made_with_Ky-built_satellite_CXBN/

10khz was the discussion we had about doppler and how to deal with it, and that the radio could cope with that shift they were happy about.

I dont thing you need much trig to work it out, I would presume that the shift is a simple fraction of the speed the satellite is coming towards you in relation to the speed of light.

Take worst case of the satellite coming directly towards you just popping over the radio horizon, the speed is about 27,000kmh, which is 7500m/sec

Shift is (maybe) 7500/300000000 = 0.000025 which at 437Mhz is 10.925khz
 

Dippy

Moderator
Well, Doppler is about relative velocity and , more precisely, resolved relative velocity.
With you sitting on a circle with (for an easy life ) the RF transmitter moving at a velocity in an orbital circle the relative velocity changes depending on relative position.
And to resolve the vector component ....

Anyway, if someone has already done the 'worst case' for you then all the rest is something to do when wallpapering becomes too boring :)
 

srnet

Senior Member
Well, Doppler is about relative velocity and , more precisely, resolved relative velocity.
With you sitting on a circle with (for an easy life ) the RF transmitter moving at a velocity in an orbital circle the relative velocity changes depending on relative position.
Sure, but as the actual relative speed will always resolve to less than the worst case, so I saw no need for further calculations.

Explanation here;

http://www.qsl.net/vk3jed/doppler.html
 

geoff07

Senior Member
If you want code to calculate position and frequency based on the keps, take a look at Plan13 (by James Miller G3RUH published in Amsat-UK's Oscar News, 1990 Oct No. 85 p.15-25 available via google). It is written in BBC basic, using FP but won't run on Picaxe use to lack thereof. I have a long term project to convert to a PIC (in C because of the need for floating point). I did consider WA55's code and also the FPU but they proved too difficult for me given the time I wanted to spend on it. All the vector calcs to convert coordinates and calculate doppler are in there. It uses the NORAD keps as the starting point, presumably they will be available for this sat?
 

Dippy

Moderator
Well, I was just thinking out loud.
Um... I think most other conditions will resolve to less than worst case :) :)
Hopefully you can now see how useful trig is.

Anyway, move on; I don't want to see poor Google overworked...
It's sometimes nice to work things out from basic principals rather than reach for the online calculator.
Keeps the old grey cells employed ;)

Good stuff. Can't wait for launch (or lunch). And good luck with it.
 

geoff07

Senior Member
I can't argue with the sentiment but you would need quite a few grey cells to do this job! It is surprising just how complex the calculations are when you start from the kepler elements (which are the only data you have once the sat is launched - 7 numbers, courtesy of the USA and their NORAD space object radar tracking capability - thanks guys). You have three sets of 3D co-ordinate systems to worry about - Celestial, geocentric, and orbit plane, and there is a mass of vector computations to do. A quote from James Miller's paper: 'SGP, the simplest model, runs to 4 pages of higher mathematics just to compute satellite position and velocity.' though he implements a shorter approximation. You then have to calculate antenna angle and doppler (the easy bit) so you can point the antenna and tune the radio. Unless there is enough in the power budget to drive a vertical rx antenna - which I am not clear about in this case.

My sat station (long dismantled sadly when I went to work abroad in the late '80s) had two 15 foot long crossed yagis on 144 and 433MHz, and the ancient pc that ran it (16MHz 386 with 16MB ram) simultaneously calculated the position of the upcoming sats, pointed the antennae and tracked the sat across the sky, tuned the radio as it went, downloaded and uploaded the data which it coded and decoded and presented to me in a GUI. Sadly the WISP and KCT technology involved did not survive the advent of later Windows versions and the PCI bus. The window cleaner nearly fell off his ladder once when it powered up unattended when a sat came past. I do plan to resurrect the station with new technology as I still have the FT-736 transceiver and the antenna rotator, but somehow it never gets enough priority. Maybe this project will help push it up the list!
 

srnet

Senior Member
We were having a discussion on the NORAD tracking (last Thursday a weekly Internet conference with the Guys in the US) as to whether they will actually be able to track this thing, there seem to be some question as to whether they can, as they claim, track as small as nuts and bolts.

Anyone know if a streamer made of the metallised mylar, the type in a capacitor would provide a bigger RADAR profile for NORAD ?
 

Paix

Senior Member
From either the C4 or the Delfi-C3 launch, I gathered that at reaching the altitude for orbit, the various satellites were ejected from the launch vehicle and individually allocated a Norad #. AO DO etc. designators came later. There was a bit of difficulty as I recollect in identifying which bird was which as there were, I think, up to six satellites in the launch package. As they each moved apart and into their individual orbits, the situation became clearer which Norad # was the one of interest to the appropriate ground station. So a bit of a scrabble initially. I don't know how this early communication with Norad space-track.org was negotiated, but organisations that participate in these launches obviously have an intimate relationship which must have the lines buzzing around the time of orbital insertion. This is where the Morse ID beacon and a large audience pays dividends as Amateur stations on the other side of the world can often be the first to let you know that your bird is alive and the transmitter working. I believe that it took up to a couple of days for the confusion to subside (maybe less) and to know which vehicle to track. The satellite designator was confirmed shortly after this process had been sorted out and TLEs became publicly available. They were available published directly from the team who obviously had an early heads up from the trackers.

Programs, such as Sebastian Stoff's Orbitron and others require your location information, relevant up to date TLE data and for the radio up/down link frequencies. The program provides the instantaneous azimuth and elevation data, as well as the instantaneous up and down frequencies. The update period can be one of several selected between one and sixty seconds. With control of rotator tracking and radio tuning, life is good.

As Geoff07 pointed out with his reference to 'Wisp', a number of interface protocols are implemented: Alarm, WispDDE, SpidAlpha and MyDDE. These are all apparently Windows client server protocols which may or may not have survived the test of time. The program is well respected by amateur and professional trackers alike and appears to work well using WINE under Linux, but it is no longer under development. Personally I have no knowledge about how to get at the AZ, EL or frequency data. Any advice gratefully received.

There are other programs out there that do a similar job, such as &#8220;Ham Radio DeLuxe&#8221; to name but one.

On the question of improving the radar signature, that's one for those that know about those things.

Such projects deserve to receive lots of support from those that can make a ground station contribution and with ADC converters built into PICAXE chips, the design of DIY rotator controllers has become a lot easier.
http://www.electric-web.org/tracking_antenna.htm

Does my passion show? ;-) Lots to glue together with PICAXE projects, for sure!
 

srnet

Senior Member
Temperature tests on processor radio board.

By recording the audio produced from the RF transmissions of the processor radio board it was possible to measure how much the PICAXE internal RC oscillator varied with temperature. I compared with a sound file editor the time between the end of the slow Morse beacon and the start of the fast Morse, this is the period that sat is listening for a command telemetry packet. With no packets to receive this time should be a function of the processor clock frequency.

+70C, 10.58secs
+40C, 10.53secs
+25C, 10.48secs
+0C, 10.48secs
-20C, 10.48secs
-40C, 10.53secs

So very little change, the difference between the highest and lowest time (i.e frequency) is only 1%.

The tests were carried out by a colleague in the US.
 

MFB

Senior Member
There having been many discussions here about the effect of temperature on the PICAXE internal clock but few test results. This look good because many applications would not be adversely effected by a 1% change. Although not a problem for you, I wonder what the spread would be between individual PICAXE chips of the same version?
 

srnet

Senior Member
Hope RF now have the RF23BP available, 30dbm\1W in a 33x18mm package, looks like its the equivalent of a RFM22 with a PA stage added on.

Now that makes the downlink of data telemetry from circa 1000km range, much more achievable.

Despite the increase in size over the RFM22, the more powerful device will fit on the PCB size limit we imposed for the project, 40x40mm.
 

geoff07

Senior Member
Do you have any details of the planned launch date, frequencies, orbit data etc? I should start to dust off my rig and get some kind of antenna up.
 

srnet

Senior Member
Frequency I know, but the rest is not firmed up as yet.

It was planned for October, then November .......
 

srnet

Senior Member
Just been testing the RFM23BP, its the 30dBm version of the 20dBm RFM22B tranciever, code and register compatible.

Range testing sugegsts a 12dBm power gain and 4 times the distance over the RFM22 for a modest 3 times increase in current.

Also tried a proper 70cm masthead preamp in front of the RFM22 receiver, that gives a further 12dBm gain.

So in approximate terms these together would give a LOS range of 560kM or so, based on 1/4wave antennas.

This is now looking very promising for a data link from orbit.

Only downside of the RFM23BP is that its an all or nothing device the power cannot be turned down from 30dBm.
 

boriz

Senior Member
"...a streamer..." Prolly won't work as intended without some sort of support. No air to 'stream' it.
 

srnet

Senior Member
Atmospheric drag is one of the main causes of orbit decay, so there must be at least some air up there ?.
 

Paix

Senior Member
A streamer would increase the atmospheric drag and result in the orbit decaying earlier than it might otherwise do.

I believe that the problems with identification is likely to be because of multiple payloads deploying and the first few hours can be a little chaotic until the individual satellites have separated a little and identification can be positively confirmed by NORAD. Support teams can get quite apprehensive until it all becomes clear.

I believe that NORAD track objects the size of nuts and bolts, which is pretty scary in itself.
 

Graham O

Member
Just been testing the RFM23BP, its the 30dBm version of the 20dBm RFM22B tranciever, code and register compatible.

Range testing sugegsts a 12dBm power gain and 4 times the distance over the RFM22 for a modest 3 times increase in current.

Also tried a proper 70cm masthead preamp in front of the RFM22 receiver, that gives a further 12dBm gain.

So in approximate terms these together would give a LOS range of 560kM or so, based on 1/4wave antennas.

This is now looking very promising for a data link from orbit.

Only downside of the RFM23BP is that its an all or nothing device the power cannot be turned down from 30dBm.

How much data do you need to downlink? I've only just found this thread and with experience of high altitude balloons, 10mW FSK RTTY is relatively easy to decode at 400km. Looking at your ground based tests, you will find considerable improvements with true line of sight and with minimal polarisation shift, you should find signals are very strong with 30dBm.
 

srnet

Senior Member
For slow data we will be using FM 120WPM Morse at 100mW. Has the benefit that minimal equipment is needed to decode, a handheld UHF transceiver, yagi and PC decoding software should be enough.

There is only a small amount of power available, circa 75mahr and 4v, so to get more that a few bytes of data we need to use faster digital data. For this mission we will only be sending data at 1kbps and depending on the results we may be able to use the setup to send data at much faster rates, which in turn use far less power.

How well would FSK RTTY cope with a rapidly changing Doppler shift, +\- 10khz, ?
 

srnet

Senior Member
Could you get over the Doppler shift problem by using AFSK?
Of course, and I already tried that with the radio, more than 3dB worse performance versus the 120WPM Morse.

The RFM22 does not allow for true AFSK, its just a square wave of 'audio' , fine for Morse not so good for RTTY.
 

Graham O

Member
In the UK, balloon tracking is done with a modified version of fldigi which has automatic frequency control and I've certainly seen some signals drifting (due to temperature or low batteries) by more than 200Hz per 15s data packet. The +/-10KHz doppler of satellites is only when they are high angle passes, most of the time it is less than this. The normal system in the UK is a licence free 10mW tx module which is fed with one of two voltages to give mark and space frequencies. At 50 baud, signal strengths are very good with a quarter wave on the payload and generally a colinear (plus preamp?) or small yagi on the ground. The limiting factor is the horizon, rather than signal strength. But as the data rate increases, so the decodable range decreases quite rapidly and the number of decoded packets is small.

My knowledge of signal theory is limited and only what I've picked up here and there. Above you say

"There is only a small amount of power available, circa 75mahr and 4v, so to get more that a few bytes of data we need to use faster digital data. For this mission we will only be sending data at 1kbps and depending on the results we may be able to use the setup to send data at much faster rates, which in turn use far less power."

It seems to me that there is a trade off here between using low data rates with high probability of decoding and the opposite situation. For a typical 10 minute pass, you have about 1800mW of power available if my calculations are correct. If you run high data rates, you need a higher power to make up for the reduced s/n ratio. If you run slower, then less power is possible as the s/n ratio is higher. I'm not sure that it would use less power to run at higher data rates.
 
Last edited:

srnet

Senior Member
If you run high data rates, you need a higher power to make up for the reduced s/n ratio. If you run slower, then less power is possible as the s/n ratio is higher. I'm not sure that it would use less power to run at higher data rates.
That is what classic theory would suggest, but in practice does not appear to be the case with the radio we are using. The difference (in dBm) performance terms, between 1kbps and 5kbps, is small and the 5kbps uses approx 1/5th of the power. For now we dont need more than 1kbps, that is where most of the testing had been done so that is being used.

And the reason for fast Morse was so that meaningful data could be received on a simple UHF handheld.

Most of the available power goes on a slow Morse beacon, 100mW, there is not a lot left for much else.
 

Paix

Senior Member
How much unique data will be transferred on each optimal pass, or put it another way how long is your data message in characters?

A burst of data may be affected by doppler, but if you are processing that data off line, then it can be sorted. All you need to do is to keep the signal as near to the centre of your receiver's band pass filter as possible. Imagine that someone is transmitting on SSB. You tune the signal for most smoke, but it is entirely unintelligible because unbeknown to you the radiated signal is LSB and not SSB. So what do you do, given that you are already recording the signal? Well, if the received signal is passed back through a mixing (modulate/demodulate) process not only can the opposite sideband be selected to uninvert the signal, but frequency adjustment of the carrier insertion oscillator into the mixer can be adjusted in order to correct the tuning of the resultant audio. So the signal is not a snapshot in time, it persists and can be corrected. The big boys can do it in realtime so much better than we can, but that's the process and the advantage of actually using AFSK with FM or using a SSB receiver to produce the audio tones recovered from a FSK transmission, in the same way that the BFO resolves the on off keying of CW into a received tone. With FSK, whether transmitting a Morse, RTTY or ASCII signal you have twice as much information to play around with than you do with on off keying. the trade off is that on off keying will save around 30% on the transmitted power budget with the key-up between symbols and characters etc. Faster transmissions will mean less transmission time, but greater power bandwidth. Select your transmission speed such that you deliver the punchiest signal (slower) to your groundstation audience commensurate with being able to take at least two bites of the cherry on every good pass that the satellite makes.

You should get around three good passes aper day with the satellite elevation better than 25 degrees above the horizon. Best case might be a pass as long as 10 minutes and worst case between 4 to 6 minutes. How frequently will the dataset be repeated, in order that you can get more than one bite at the cherry on each pass. It is a moving window after all.

The main downlink receiver is to be a fully specified communication receiver I presume and not a handheld transceiver?. No point in the official downstation to be vastly outperformed by the local ham radio operator unless some effort has gone into including him/them into your program.

I would imagine that by now your transmitter options are pretty much frozen, but if you have made the right choices you can still exercise receive downstation options, even to the point of post reception processing of the acquired signals. Never say Never!
 
Top