28MHz QRSS beacon

Well, as promised elsewhere - a quick update on where I am with the 10m QRSS beacon project. 

I decided not to bury it!  Instead its going to live on the rack here in the shack / server room. Temps in here are fairly constant, but I decided to try adding a thick layer of thermal insulation around the beacon to elevate its temp to help buffer it from minor temp changes in here.  This may not be ideal!

Read on...

Here we see the completed beacon PCB inside a diecast box.

The device poking through the lower edge of the box is a thermocouple. It is directly above the oscillator crystal - so should give a direct readout of the temperature inside the box nearest the xtal.

 
This can be seen in more detail in this image.

Here we see it with the lid on the diecast box, inside its outer casing. The thermocouple is showing at that stage about 4 degrees above room temp - and a current drain of 90mA.

Now we see the digital thermometer mounted on the front panel, along with keyswitch and power LED.

The next stage was adding the thermal insulation - in this case polystyrene beads.

.... until it looks like this.

And then we quickly screw the lid down before all the beads escape!

And there it is sat on the rack.










So, tests began about 5 hours ago. Once every five minutes I recorded the xtal temp, and the frequency in Hz (audio) with my RX set to 28.000 MHz CW.

The beacon is at present TXing into a dummy load with lose coupling to the RX. (Im still torn between a half wave end fed vert and a halo when I do get an antenna up - but thats another story!)

Im using my usual studio quality soundcard (24bit) to sample the recovered audio from the RX, and used Baudline (an audio analysis tool) to take measurements of the frequency of the mark and space tones. This provides an accuracy roughly on a par with my frequency counter, (limited by the unknown drift on my RX in fact) but makes it easier to read the changing frequencies brought about by the FSK which on a counter is a bit of a pain.

yes - the FSK is a bit on the high side - about 8Hz - I was aiming for 5 but with the lid on and temp up the FSKing is also slightly increased.


These were the figures for the first 3 hours:

 (Raw data follows.)


mins  temp C  freq Hz
0     25      760
5     25.6    748
10    26.9    741
15    28.2    740
20    29.4    742
25    30.5    748
30    31.7    758
35    32.5    766
40    33.3    769
45    34.2    772
50    34.9    775
55    35.5    778
60    36.2    782
65    36.8    787
70    37.2    792
75    37.7    794
80    38.2    799
85    38.5    801
90    38.9    805
95    39.3    809
100   39.5    811
105   39.8    815
110   40.1    817
115   40.3    820
120   40.5    822
125   40.8    824
130   40.9    826
135   41.1    828
140   41.2    830
145   41.3    832
150   41.5    833
155   41.6    834
160   41.8    835
165   41.9    837
170   42.0    839
175   42.1    839
180   42.1    840

After 3 hours I stopped taking five minutely readings, and checked sporadically.

After 5 hours the Xtal temp had reached 43.5cand the frequency had reached 858Hz thats around 100Hz moved for around 20c temp change.

Although the values where beginning to flatten off, I pulled the plug after 5 hours as I feel that the thermal insulation is perhaps just a little too efficient!

Looking at the mark and space data on the display it was clear that once the xtal temp was past 33c that there was slightly more 1Hz jitter on the signal. No tests done to confirm this or the cause yet - but Im guessing that the PA transistor is sitting a fair bit warmer than the xtal and may be running away a little.

My main worry though is that as this will be operating as a MEPT (Manned Experimental Propagation Transmitter) to remain within licencing conditions it  will spend some quite sizeable times powered off when Im not physically here. The long ramp up time to stability  is not going to be condusive to a device that is turned on and off frequently. (As I am writing this the temp has dropped by over 3 degrees in 8 minutes, showing that cool down is much swifter than warm-up).

I think I may need to add a simple heater circ to the diecast box for more rapid warm ups, and to limit the upper temp to about 30c.

More tests will follow...

ICT is not CS

Its been a while since I did a wordy post, but having just watched a short video from the beebs archive, its prompted me to comment on something I feel strongly about:

ukict != cs;

Sadly thats not going to mean a lot to most people, and therein lies my point.

In my opinion the current UK schools curriculum subject ICT is not fit for purpose. It is simply not a substitute for teaching Computer Science. It is creating a generation of mindless point and clickers.


And it seems Im not alone in this worry. Have a look at http://news.bbc.co.uk/1/hi/programmes/newsnight/9612063.stm


Some schools even struggle to teach the basic ICT curriculum particularly well, but in reality what they need to be looking at is a return to teaching Computer Science. Scary - but its time for a rethink.

When I was growing up, if I wanted to play a computer game, I had to write it. Yes really write it - type in the code, line by line. I realise that for most people under the age of 35 thats kind of shocking now, but really thats what we had to do. The thing is, the need to do that, to develop your own software is now long gone. These days you just download an app yes??, or bung in a CD.....?

But ask yourself - where do these apps come from??? Someone has to write them.... That would be the software developers.

At school us forty-something developers did "computer studies". We learned all the basics (pun possibly intended!) of the nuts and bolts of how to write software. We also covered fundamentals such as boolean algebra and binary math. Yes, I know they are mentioned in the current curriculum - but thats it - they are just mentioned.

There is a whole generation now  who are, and probably only ever will be IT consumers rather than IT creators. We are educating the masses to blindly use software created by others rather than innovating new software ourselves.

We have to tackle this with our current teenagers or risk a huge skills gap in the future.

As followers of my assorted blogs will know, we have an "Emily". She is our daughter, and we think she is amazing. In a lot of ways however, she is very typical. Very typical of a bright 13 year old. She does well at school, but would take exception to being thought of as "Geeky".

The thing is that despite this non-nerd status, with a few sessions of goal based,workshop style teaching at home and a LOT of support on the practicalities of turning "what-if" into "how-to", Emily is able to turn out things like this:




For those of you who havent already seen it, thats live and historical data coming from a set of network connected sensors (which emily mainly designed and built) being collected, stored, graphed and pushed back out to the web using software that Emily herself wrote with very little help.

see http://myweatherblog.wordpress.com/livedata/ - you can read about some of the technology behind it here : http://myweatherblog.wordpress.com/equipment-4/

With project-based workshops and goal-based motivation as the teaching method Emily has gained a good enough basic grasp on simple digital electronics, networking, programming and databases to achieve all this in a little over 12 months - probably equivalent to 3 terms classroom time.

If im honest, I would say with the same level of help MOST children in Emilys class at school would be able to cope with the key aspects of how this project works and as a group project would find it both attainable and enjoyable.

The import thing here is that actually projects like this tick so many of those all important ticky boxes for cross curricular attainmnet and key skills that it makes your hair curl!

So what is the current ICT curriculum asking them to do? Well, a lot of it focusses on skills like how to open a spreadsheet, create a powerpoint slide, turn the computer on and off without breaking windows. All valid skills - as an IT consumer - but not exactly inspirational for the next generation of Uber Developers.

An understanding of the mechanics of computing is not something we can just leave until AS level and hope that a few "bright" ones will stick with ICT long enough to want a career out of it. And a couple of lessons spent creating a web page with WYSIWG editor is NOT learning about programming. The science part of computing has to be there from the earliest days of learning.

So... what can we as parents do? Well, I suggest you buy one of the many workbooks available for the current curriculum and make sure that your childs school is teaching the existing curriculum well. But also to see what is not being taught.


We can of course lobby the government to rethink computing education in the UK - but educational reform tends to be a slow process, so we need to think about the short term too.

If you have the skills, you could do what a lot of us do and not only help our own children, but to volunteer to help run afterschool classes and groups to bring technology to the kids.

But, if I had to chose something to say to all parents to help their kids WANT to take a deeper interest in IT and technology - I suggest the age old way of teaching kids techy stuff - make it fun!


Download a copy of Scratch developed by the Lifelong Kindergarten Group at the MIT Media Lab (its free! - and windows/mac/linux flavours) and buy them a copy of this: Scratch programming for Teens










If you were paying close attention to the BBC video at the top of this post you might recognise the above image.

To pinch a quote from the scratch website:

"Scratch is a programming language that makes it easy to create your own interactive stories, animations, games, music, and art -- and share your creations on the web.


As young people create and share Scratch projects, they learn important mathematical and computational ideas, while also learning to think creatively, reason systematically, and work collaboratively."

Scratch is the Lego(tm) of the programming world. You literally drag and drop building blocks of code together graphically to add interactivity to objects. Its quick, easy and intuitive. But it is based on real programming constructs - decisions, loops, conditionals, variables, objects and actions.

Scratch was the first programming language Emily learned. I didn't teach it to her. She learned it. I simply installed a copy on her PC and said "hey - check this out - its kinda good". And she got it... She just Got It. Yes, I've offered the occasional bit of help now and then - and perhaps suggested she look again to see if the was a simpler way of doing something. But Scratch teaches itself.


Based on what She has learned, Emily now programs in varying degrees of depth - Arduino, C, Processing, PHP, MySQL and the Linux shell Bash. She still has a lot to learn, but she has the fundamentals and thats the key. She knows how to do useful stuff, and knows how to find out stuff she doesn't know. And that the core skill of anyone working in software design, or electronics, or engineering etc etc etc.

And if you are thinking that OK Scratch looks cool but what does it lead to?? - well... as commented above Emilys grasp of programming constructs come from her introduction via scratch, but sticking with graphical block programming for a moment further - the concept has been carried forward - again via MIT and Google - to produce App Inventor - the graphical development language for Android based mobile phones and other devices.





App Inventor will be Emily's development platform for a whole host of new projects over then next couple of years.

So Go ON! Get your kids into something thats going to change not just their world - but everyones. Who knows, the next app you download to your phone might have been written by your son or daughter!


Some more links (from Emily's bookmarks) to play with:

http://makezine.com/
http://arduino.cc/
http://mindstorms.lego.com/en-us/Default.aspx
http://www.adafruit.com/blog/about/
http://www.oomlout.com/a/
http://www.modk.it/
http://processing.org/
http://hackaday.com/
http://www.instructables.com/

Ts140 repair

I had a spare few mins this afternoon so I thought I would tackle the intermittent audio fault on my TS140. Previously I had traced it down to the external speaker socket on the rear - it seemed to be dependant on the angle of the audio jack as to weather audio came out of the external speaker - but if unplugged audio did not always return to the internal speaker via the make/break contacts in the socket.

I was hoping a squirt of switch cleaner was going to solve the problem, but no - as I feared it was a broken joint on the PCB under the socket.



Every last nut and bolt out to get to it and the zillion and one mini connectors undone before I could lift the PCB to get to solder the joint. Im not usually squeamish when it comes to repairs, but this one had me sweating! The TS140 was built between the times when you took your rig apart with a hammer, and recent tech where basically you dare not take a bolt out of the case - (and even if you did what would you change?) So it has an overly large number of interconnections and lots of scope for making existing dry joints worse.

Thankfully it now seems happy - Even with the lid on!

Morse wine

Todays discovery