Jason F Ball

Going Portable (HF Radio)

2015-04-04T17:27:00.000-07:00

I'm in the process of changing my radio setup in the Patrol, to allow me to easily switch between Mobile and Portable operations for field days, when I'm camping, and for the occasional SOTA activation. I currently have an FT-857D in the patrol, and looking to setup this radio for a simple transition between mobile and portable use rather than spent for yet another radio.

The FT-857D is a relatively small, portable all mode all band radio and was the first HF rig I bought when getting into the hobby. For the past couple of years its been permanently mounted in the car, but doesn't get a whole lot of use in that mode as children-in-tow doesn't really lend itself to many contacts when mobile.

I did get very lucky here and acquired the perfect pack for this radio from another member of the radio club who has upgraded to a more modern, lighter, and more portable radio for his ops. And when I say perfect, I mean it as this pack was made specifically for the FT-817/FT-857 radio's.

I've currently paired the radio with an LDG tuner which won't be necessary for most bands as I'll be (trying) to use resonant antenna so don't plan to carry the tuner for SOTA/qrp ops.

A Signalink has been added to enable data modes (PSK-31, JT-65, etc) and a 8.5 amp hour LIFEPO4 battery to run the rig when I'm away from the usual power sources (solar).

Everything fits nicely in the pack, and it opens up when in use to allow the radio to breath (dissipate heat) when in use. I've brought all connections to the front of the pack (HF/VHF/CAT/Data/Power) for easy connection depending on what I'm going to be doing at the time.

I was hoping to leave everything in the pack in the car by simply plugging in the power/antenna and moving the head unit, but obviously cooling the radio will be an issue in this mode in the car so some thought needs to be given to this setup. I'll probably have to move the radio between the pack and the car which isn't a huge deal.

The entire pack weighs a few Kg so it's not that light weight, The Lifepo4 battery is a good deal lighter than the equivalent SLAB and the voltage range is perfect for this radio so no voltage regulator required.

I still need to sort out portable PSK-31 as I don't really want to carry my macbook up a mountain where its likely to fall victim to the inclement weather. I am working on 'fixing' my Nexus 7 for this, or may jailbreak the old Chromebook my daughter has decided is no longer suitable for school.

All in all I'm happy with the solution so far.

Now to add:
* Squid pole
* Resonant antenna for the usual bands.
* carry capability for water/food/raincoats etc.

Hey - my first 'official' puppet module... autossh

2015-01-08T21:20:00.002-08:00

Well while I've been working with Puppet for several years now I've (ashamedly) never actually contributed back to the Puppet Forge, which is a repository for publicly contributed puppet modules.

Well that's changed now ;)

https://forge.puppetlabs.com/agronaught/autossh

I'm currently working on a solution where multiple 'ssh tunnels' will be used to provide an excrypted link between to servers. In this instance VPN isn't applicable, and in this particular use case 'ssltunnel' isn't suitable either but that's getting a little off topic.

The 'autossh' wrapper is a nice little utility, albeit not pre-packaged by the more popular enterprise distributions.

autossh http://www.harding.motd.ca/autossh/

A quick look at the Puppet Forge revealed a couple of other modules people had written, while these formed a starting point they were well short of the functionality I was aiming at, namely:

Install the required package support.

Configures the 'autossh' configuration file.

Creates a system initialisation script (init script).

exports resources to automate the configuration of the 'remote' nodes.

automatically configures remote nodes to provide a secure tunnel capability.

Support for multiple tunnels on any given host.

Support for Hiera integration

Support for configuration of the 'tunnel endpoint'

Secure configuration of the tunnel endpoint.

Customisation of the important ssh configurations for the ssh tunnels.
Support for both SYSV and Systemd.

So I've written the package to provide the above.

So now, creating an ssh tunnel is as simple as:

class { '::autossh':
}
 autossh::tunnel { 'port_25_tunnel_to_server1': 
  port             => '25',
  hostport         => '25',
  remote_ssh_host  => 'server1',
  pubkey           => 'ssh-dss '
}

And on the destination node:

class { '::autossh':
}
 autossh::endpoint { 'load ssh endpoints': 
  host   => 'server1',
}

Pico Tracker (ballsup1) - prototype games... (and a working bootloader!)

2014-09-06T18:42:00.004-07:00

I've been working on the initial tracker boards and to some extent fighting with bad decisions, due in part to lack of experience in these things. Live and learn.

In the design process I decided to drop the usual 6 pin ICSP used on these projects as I had one of these adapters from Hobbyking and have successfully used it on a number of projects:

Atmel_Atmega_Socket_Firmware_Flashing_Tool.html

This is a useful tool where there are suitable clearances around the processor and a great tool for flashing the final software to the microprocessor. Unfortunately in my case I've learned the hard way that its not such a great tool for development of that firmware. With repeated use there is an increased risk or bridging pins with the tool and I now have a couple of truly dead microprocessors to prove it.

Lesson learned. The next revision of the board will have the necessary headers...

Fortunately the combination of exposed via's and hot glue means I could wire in an ICSP and get on with developing the solution. That means I can also take my time with some of the design revisions before getting more boards made.

The second and extremely annoying problem is the footprint for the 4MHz resonator. I used a footprint I have used in a previous design, unfortunately when the resonators arrived the footptint is very different, out by almost 1mm across two of the pads which makes them unusable in this design.

So far I haven't managed to find any suitable components with the 'correct' footprint... bugger.

Again so I can make progress I'll use these boards to build up and test each part of the circuit in isolation and when I'm ready I'll get boards made to correct this problem.

Changes to the design so far:

Add 0 (or low) ohm resistors to each section of network to allow those sections to be isolated from the power supply during programming and testing.
Consider moving all components to the top side of the board, simplifying routing on the rear of the board and enabling everything to be reflowed with no manual soldering.
Add an ICSP header. Always.

And I'm sure more will come up later.

The following arduino bootloader configuration is needed to support the internal 8MHz oscillator while I develop the software stack:

##############################################################

PicoTracker.name=ATmega328 Optiboot (8MHz internal clock)

PicoTracker.upload.protocol=arduino

PicoTracker.upload.maximum_size=30720

PicoTracker.upload.speed=57600

PicoTracker.upload.tool=avrdude

PicoTracker.bootloader.tool=avrdude

PicoTracker.bootloader.low_fuses=0xE2

PicoTracker.bootloader.high_fuses=0xDA

PicoTracker.bootloader.extended_fuses=0x05

PicoTracker.bootloader.file=optiboot/optiboot_atmega328.hex

PicoTracker.bootloader.unlock_bits=0x3F

PicoTracker.bootloader.lock_bits=0x0F

PicoTracker.build.mcu=atmega328p

PicoTracker.build.f_cpu=8000000L

PicoTracker.build.core=arduino

PicoTracker.build.variant=standard

This needs to be added to the Arduino/hardware/arduino/avr/boards.txt file.

GPS Governed OCXO - Part 7 - GPS Survey

2014-09-03T04:29:00.000-07:00

The GPS antenna finally arrived and I had time to run a cable from outside into the workshop to feed the signal where it was needed, hooked up the Navman Jupiter tu60 GPS and fired up Tac32 to monitor and configure the unit.

The test setup may look a little on ugly side, but its allowing me to validate what I'm being told on a number of fronts. I have the DSO and HP5384A hooked up to monitor the 10KHz output from the GPS module, this feed will be used to discipline the OCXO shown in the prior post to the accuracy is... critical...

First off I have the windows application 'Tac32' talking to the GPS via an FTDI cable to monitor and configure the module. This is a nice piece of software and is available to licensed hams who are members to TAPR at a discount price...

It looks like I'll need to join TAPR ;)

The software and GPS module are currently running in 'Survey' mode while the module works out as accurately as possible my location using a 3D fix. Once the module has established that location it will switch into a precise timing mode which is where the precision of this module kicks in. The Jupiter-T is accurate to within ± 40 ns of UTC time (or 4*10^-9).

Jupiter Tu60 Datasheet

It was interesting to see the 10KHz frequency change on the frequency counter as the survey was running. It started out jumping around a lot at +-50 pulses per second, and has now locked in at precisely 10.000000Khz on the frequency counter.

This is seriously cool as it means:

a) The GPS is doing what it should.
b) The frequency counter is also accurate at this level.

Its interesting to note that the Rigol DS1074's frequency counter is displaying 10.0001kHz. That last digit doesn't seem to change much...

I'll leave the survey to run until its completed which will take a while, and then program in the position of the antenna and see how it goes. Hopefully the GPS simply starts up doing the right thing when the software isn't connected to the system, hence all the independent measurements.

This 10Khz output will be fed into the OCXO PLL board and used alongside a stepped down 10KHz signal from the OCXO to establish a phase lock on the OCXO. Once 'disciplined' the OCXO will deliver ±0.5 ppb or +-5 pico seconds (5*10^-12) resolution at 10Mhz, potentially 10^-13 depending on the PLL loop time constant et al.

The hard part will be proving that I've achieved that accuracy.

GPS Governed OCXO - Part 6 - PLL Board

2014-09-01T06:27:00.000-07:00

I'm taking a little time out on the pico tracker while I mull over some complications with the design, nothing that can't be resolved but some thought time is needed.

As a break from that project I've started assembling the PLL board

Other pages for this project:

gps-governed-ocxo-aka-10mhz-gps-time
gps-governed-ocxo-aka-10mhz-gps-time - part 2
gps-governed-oxco-part-3
gps-governed-oxco-part-4
gps-governed-ocxo-part-5-evolution-of

The PCB from osh park is great, I dare say perfect. As size isn't an issue in this project (unlike the pico tracker) I was able to use larger components and keep well away from the minimums for all traces and via's, and this shows in the finish.

Unfortunately where I thought I had all the components i'm short:

1 * 10uH 1210 ~500ma inductor.

I just noticed jaycar have 100uH inductors in the correct form facter, so price/availability etc. Cheaper than a small order from element14 or digikey.

1 * 100uF SMD capacitor
1 * 1N4001 SMA Diode. (I do have a schotty in the right size though.. Melf pack... blek!)
1 * Recomm R-78HBXX-0.5 DC-DC regulator. (I was sure I had several of these).

As such, this will have to wait. I'm very happy with how this has turned out so far and really should get on and complete/order the GPS board.

Note - the OCXO hasn't been soldered in place. That would make installing the inductor a little... difficult.

However it just occurred to me that the placement of this component next to the metal can probably wasn't the best place I could have put it. Its not a big issue as this is simply a filter to block any noise from the regulator/supply and could probably be dropped from the circuit.

So need to...
* order the GPS board.
* order remaining components.
* find a box to put it in.
* think about the micro controller circuit.

Pico Tracker (ballsup1) - board 1, some issues...

2014-08-30T17:14:00.001-07:00

Ok, so some lessons learnt with board number 1, nothing that can't be salvaged and I have a number of spare boards to work with.

The first step was to flash the microprocessor, and I noted that the programmer was shutting down when connected which isn't a good thing. A quick check found the resistance across the power lines to be a low lower than it should be... so we had a bridge or similar in the circuit.

I started by removing the likely candidates, namely:

* GPS -- the alignment on the pads could have been causing an unintentional brigdge.

Nope, wasn't that.

* Oscillator -- it didn't look right to me anyway, and as I suspected one of the pads on the oscillator didn't have any solder contact so it needed to be reseated anyway.

* VCXO -- and bingo, the short was gone. I'll need to dig into this, its possible it was a simple orientation problem. Hopefully I haven't damaged this heat sensitive component during the process, I can probably dead bug it to make sure.

The most notable lesson here being:

* Add low value resistors to the component power supplys, these can be used to isolate the components during testing.

* take a slightly more conservative approach in the initial builds ;)

Nothing has been lost at this point and the board is salvagable. Most importantly I haven't had to remove any of the QFN's ;)

Now back to the bootloader...

Pico Tracker (ballsup1) - board 1 assembled...

2014-08-29T20:05:00.002-07:00

I've assembled the first board which will be used to get the software working, as such the only component that will be installed on the back is the ftdi serial adapter + power, no need for the boost converter at this stage.

The picture to the left is after component placement, before reflow. This is a number of firsts for me:

* first commercially fabb'ed PCB.
* first time working with 0402's. (not as hard as difficult as I imagined).
* first time using a solder stencil.
* first time with lead free solder.
* first time making this board.

The solder stencil was expensive, but most definitely worth it as manually applying solder is a major pain in the but.

The board was reflowed using a $30 toaster oven from OfficeWorks, by reflow controller failed to power up so I manually controlled the temperature using a thermocouple to monitor the temps.

The BGA appears to have soldered nicely, as has the VCXO. I've intentionally left large exposed pads on the VCXO so I can easily get a probe in there, the performance of this component. Future boards won't have this.

The microcontroller is soldered nicely with exactly the right amount of solder on the pads.

I'm not entirely happy with the GPS mounting as I don't believe there was enough solder on the pads, some of the buckets on the side don't have any solder at all although we do appear to have continuity. I obviously bumped the board putting it into the oven as the GPS has shifted slightly from centre, hopefully not enough to be an issue.

I did have one resister move out of alignment supporting the 'bump' theory, a blob of solder has restored connectivity here as I don't relish the idea of hand soldering an 0402.

At this stage the only component I think I may have issues with is the ceramic resonator as I'm not convinced its right. I may need to redo this one with a little hot air.

For so many firsts I'm reasonably happy. The next stage is to flash a boot loader onto it and test each component.

I'll be back later after family comittments.

New Acquisition - Stanford Research 30MHz Synthesized Function Generator - Model DS345

2014-08-29T03:14:00.005-07:00

I managed to pick up a Stanford Research 30MHz Synthesized Function Generator - Model DS345 at auction for a really good price price, one that I was happy to pay. I've seen these go for >$1000 on Ebay and this was fortunately nowhere near that.

The manuals are online here

On picking up the unit I noted that the calibration seal had been broken, the first sign that there _could_ be an issue, but I'm still hopeful. The case cleaned up nicely with a little isopropyl and externally the unit is in good condition with only a little yellowing of the plastics.

The display is bright and crisp and the buttons are in perfect condition with no faults observed.

As it turns out this is ex-UTS (university of technology, sydney) so who knows how well its been cared for. I suspect its had very little use in its lifetime.

Now at first I thought it may have the OCXO (Option 02) option installed, but on testing and closer inspection it turns out that wasn't the case.

With what the unit cost me I'm not complaining.

Now as the unit is out of cal (unknown last calibration) I wasn't expecting much, and after allowing it to heat up I found the following on the frequency display... 10MHz in, 10Mhz on the meter.

So here's me thinking... cool ;)

After allowing a further 20 minutes the frequency on the meter dropped and continued to drop... not so cool :(

Now the signal generator is rated at +-2ppm on the 'standard' timebase which means at 10Mhz the actual frequency could be anywhere between 9.999980MHz and 10.000020MHz.

The frequency counter is displaying a constant 9.9999908Mhz which means it is within spec as outlined in the manual.

I'm currently building/waiting on parts for a GPS Disciplined oscillator which should get it closer to 0.01ppm or 9.999999.9MHz to 10.000000.1Mhz but more on that in another post.

Opening the unit up we have the rear side of a circuit board that has been hinged for easy access, a nice touch really.

Swinging this panel open shows a busy box of bits, I have to admit I struggle to see where an optional OCXO could be installed. There is one possibly dodgy repair where a resistor has been bridged directly to the AD7547 D/A converter, but I'll need to check the schematics to see what's going on there as this could have been an original 'modification'. There's no evidence of a board level repair.

As the function generator is working perfectly and I need to get a radio and bits assembled for a buyer tomorrow, I'll leave it at that.

I'll post more once I have the GPS Discipline working as it will be interesting to see how it all works out.

All in all a good buy and this kit will be extremely useful in my radio projects.

Pico Tracker (ballsup1) -- PCB's have arrived!

2014-08-26T01:19:00.001-07:00

The first batch of PCB's have arrived with a couple of extra's thrown in for added value. I'm happy with the results, the only 'fault' is I wanted the via's covered by the solder resist but that's a minor point and due to miscommunication on my part. Its also purely aesthetic and won't impact the performance of the boards at all.

As previously noted the size did increase marginally as I wanted to clean up the low pass filter routing. I'll address this in the next version, if there is a next version ;) Still its not much larger than a AA battery.

I've also to-date received exactly one (1) of the Si4463 transceiver module with 10 on back order so that limits my ability to assemble these somewhat.

Shown is the rear side of the board which hosts the boost converter, power connector and optional serial, temperature and barometer sensors. Hand soldering the TPS61200 boost converter is going to be a right bastard but I do have a solder stencil so it _should_ be doable with the stencil and reflow wand. I'll move this to the top side on the next revision of the board which is likely to go multilayer, but with 12 boards and three (3) to come from osh park that will probably be a while away.

Showing closeups of some of the finer component pads, namely the TPS61200 and the Si4463. you can also see some of the truncated component labels due to the exposed via's, se la vie. The exposed via's will help with debugging ;)

Unfortunately I won't have time to build one until the weekend, and then onto the software.

Thanks to Mitch at Hackvana for these boards.

Noise Mystery... Solved! (well, found at least)...

2014-08-24T04:41:00.002-07:00

I've been a licensed radio amateur for a few years now, and up until this year the base noise level at my home QTH has always been ridiculously high, I'm talking S9+20db kind of high. For the first couple of years this essentially left HF unusable, and my limited experience didn't help.

My first radio, the Kenwood TS-520S simply didn't cope. It was (and is) an excellent radio, but the noise floor was more than it could handle. Fortunately I didn't give in.

My second radio the Yaesu FT-857D didn't really do all that much better, admittedly it does do reasonably well now that I know how to actually use the many filtering capabilities it has. This radio is now permanently mounted in my 4WD and used mobile and camping so the localised noise is less of an issue.

My third purchase was a Kenwood TS-850SAT and a beautiful radio it was. I discovered HF with this radio as it had something I hadn't dealt with before... filters. Real, physical, crystal filters.

With this radio I could locate a signal and engage the filters to block out the spurious noise, and it worked reasonably well. I had my first DX on this radio and would still use it daily if not for the capacitor plague. The radio still works and I occasionally pull it off the shelf to replace more of the caps, sadly it doesn't see a lot of use as any use is causing damage until the full recap has been completed.

Early this year I bought the Icom IC-7100 and what a dream it has been to use. This radio was attractive as it has a lot of the filtering on the IF rather than the AF stages, and as a result this radio simply sheds the broad banded noise and is an absolute pleasure to use. I've now had 40+ low power dx contacts with this radio and I simply love using it. I'm now starting to use this radio for EME with the local club.

During all these (expensive) lessons I also started building the Genesis G59 SDR, but shelved the project due to renovations and other family challenges. I've recently rebuilt my workbench and pulled this project out of the cupboard.

Now over this time I've had a number of theories about the noise floor I've been seeing with most local hams simply stating that its simply the way it is. I toyed with the idea of it being front end overload due to a radio station or similar to have the suggestion, in some cases, laughed at. I came to this belief through observation and coming to understand the key differences between these different radio's.

As it turns out, front end overload IS due to a local AM broadcaster, and is very much an issue that I have to deal with.

I've not long plugged in the G59 and noted a fairly large signal across 'all' the bands the radio supports. At this stage I've not added the front end band pass filters, the RF is fed directly to the receiver which means all the broad banded noise is fed to that receiver. The first thing I noticed was a base S9+20db on the power meter. I had noticed this a couple of years ago but didn't know what I was seeing, now I know better.

To be honest there were other overpowering noise sources as well such as faulty power poles which have been gradually removed. The high noise floor has always remained.

Believe it or not what you are looking at is an AM signal, while not in this screen shot the digital sub carrier is clearly visible and setting the decode to AM covering the frequency range does in fact result in... music... it doesn't matter which band is tuned, the noise is there. Its not clear, but its definitely speech and music.

Im now wishing I had ignored the nay sayers several years ago and installed a high pass filter to block the AM broadcast channels.

I think I will build that high pass filter to drop the broadcasters... now I have evidence ;)

Pulled an old project out of the shed -- Genesis G59 SDR

2014-08-22T04:33:00.001-07:00

I pulled an old project out of the shed that was put there back when the renovations were happening. Its almost shameful that I'm only now getting back to stuff that was put on hold several years ago, especially good kit like this although its only now that the kids are a little older that I'm able to setup the work area again.

At the moment I'm just working through the assembly and test guide to see where I'm up to. I do remember I was missing a number of caps... hopefully i can find the correct values once I work out what they were.

This PCBGrib kickstarter I received yesterday rocks... its going to make assembling this project so much more enjoyable ;)

and time for a repair (Asus Google Nexus 7)

2014-08-21T02:17:00.001-07:00

A little over a week ago i dropped by precious tablet. I use this thing continuously, reading on the train, browsing at home, email, you name it. For all the tech devices I've owned this one gets the most use. After dropping it and smashing the screen, it had to be repaired.

i bought the replacement digitiser from EBay, and this turned out to be a huge mistake. The digitiser is glued to the LCD Panel, and what I didn't know at the time is that the glue is manufactured from the spittle of cerberus himself. I mean removing this stuff is damn near impossible and its necessary to use a very fine wire and frame to separate the LCD and Digitiser glass. Having now done this, I don't recommend it.

If you are replacing one of these screens, buy the digitiser and lcd panel already assembled. Your fingers (and local GP) will appreciate it... trust me on this.

Anyhow, i've persisted and actually used an anerobic adhesive (aka locktite) to secure the screen to the Bezel. This will take a while to set but will easily break down with a little hot air if i ever need to replace the screen again.

The result speak for themselves.

note that the protective plastic was intentionally left on as a weight is being placed on the screen until the adhesive does its business.

if i had bought the full LCD and digitiser combo this would have taken approx 2 hours by the time all the glass and adhesive is removed from the bezel. As i just bought the digitiser its taken far longer than that, and the additional $40 for a replacement LCD would have been money well spent.

Sometimes they surprise you! (kickstarter)

2014-08-20T19:27:00.001-07:00

I have to admit I haven't been a huge supporter of kickstarters, so far I've only contributed to several projects and based on a number of people I know that's not a lot. I've also been lucky in that all the projects delivered, albeit what was received wasn't always what one expected.

In this case it was the PCBGrip project:

I've actually been considering buying or making a simple set of tools to hold PCB's while working on them, face it who hasn't needed that extra set of hands when trying to solder a tricky component or to put the board into exactly the right position to hold a probe or do some SMD work.

liked the idea and laid down the hard earned, sat back and kept an eye on it.

The kit arrived this morning, and as you do I opened the box to see what I had bought to find a nice plastic case containing the extrusions and all the extra bits. A little time and watching the assembly video and I had the current board I'm working on mounted and holding a probe on a test point.

Ok, so not a great example. What is cool and blew me away is they have provided enough bits to cater for a *very* large range of mounting and workholding requirements, admittedly this is the larger kit that caters for SMD stencils.

I can see this one getting a lot of use on my workbench, especially since I'll be assembling a number of pico sized tracker shortly.

Now all I need to do is get some of the probe holders printed and I'm set ;)

Thanks Guys, I'm happy.

GPS Governed OCXO - Part 5 - The evolution of a GPS board

2014-08-19T06:02:00.001-07:00

As part of the project I needed a suitable GPS module as to provide the reference frequency to the PLL, establishing the GPS Discipline for the OCXO. Fairly simple stuff and there are a *lot* of projects out there where people have done the same thing.

I picked the Navman Jupiter Tu60 as it was

a) available

and

b) within my budget.

In this case it included a development board which I assumed would save me some time, as it doesn't work that hasn't been the case.

So the question became did I have a dud development board, a dud GPS module, or both. On looking at the data sheet for the module I noted it worked at CMOS TTL levels, while the development board was bringing this up to 12v serial levels. Beauty as the TTL levels will be far more useful in my use case.

Some proto board, headers, and an FTDI cable later I have a simple test setup for the GPS. I start the application software to configure the GPS (Motorola Binary) and what do you know, it connects and the gps starts doing exactly what it should.

So the next step was to develop an Eagle library for the GPS module (available in the git repo) and make a prototype board on my CNC. Not everything went to plan as the single sided PCB stock I have isn't all that flat... in fact is complete rubbish, but never mind.

This allowed me to test the schematic, a few simple corrections such as wiring the serial RX to the TX (and not RX to RX... Duh!) and the board works like a charm.

Unlike the PLL board this particular design is based around PTH components as I have everything I need in my component collection, no parts to wait for which is nice for a change.

So now I'm working out if I should simply make a new double sided board as the double sided stock I have is good, or do I pay the $10 per board and get it commercially made as I did for the PLL board.

It would be nice to have it all match in the final case (when I find one), but at the same its completely unnecessary and when its assembled no one will ever see it. (the case will need to be enclosed to minimise the RF interference).

I'll probably make my own, but it _is_ tempting...

Note that the above prototype doesn't show the voltage regulator, I'm running out of the nice Recomm 5v DC-DC converters and may simply use a 7805 and a heatsink that can handle the 2 watts of heat it will be generating.

I'm a little annoyed by the bad dev board though. The above module can be picked up for half the price without it.

The next step here though will be to work out the initialisation process and get a microprocessor talking to it.

This is turning out to be a fun little project, its not technically complex and is quiet satisfying with lots to learn.

JST SR Connectors

2014-08-19T03:09:00.002-07:00

Along with the Digikey delivery today was a batch of JST SR 1mm pitch connectors I'm planning to use on the Pico tracker.

The connector is only required for the configuration (and debugging) of the boards, and in this instance size is everything.

At first I was a little concerned... How the heck was I going to assemble that! and the 'official' tool is $$$ worth.

As it turns out the old 'sword of exact zero' combined with 30awg wire wrapping wire is the perfect combination to assemble these little beasties.

Much relieved :)

A nice big box of bits arrived from Digikey

2014-08-19T01:21:00.001-07:00

A nice big box of bits arrived from Digikey, only 5 days from placing the order which beats Element14 by over a month for similar components.

This provides most of the parts needed for my pico tracker project and nicely adds to my supply of microcontrollers for those off the cuff projects (ATiny45, ATMega, STM32 etc). It should be more interesting as well given I'm starting to document and share my designs ;)

The Si4063/Si4463 is proving to be an alusive bugger to get hold of though. I'm hoping to get a couple from another vendor as the major distributors are all out of stock... all of them apparently and I really don't want to wait another month or so on this one.

The first batch PCB's from hackvana and Osh Park should arrive any day now, so I really should get on and get that old reflow oven working again...

GPS Governed OCXO - Part 4

2014-08-16T22:37:00.002-07:00

A minor update today.

I'm still spending most of my time waiting for parts, at this stage I'm not even remotely impressed with the main components suppliers but I'll save the rant for later.

I spent a couple of hours making a PCB for the OCXO and PLL circuit on the CNC. As this is a one off and I'm able to avoid the really fine pitch components this board is fairly easily made.

In this case it a double sided board, all things considered I'm extremely happy with the results. With the exception of the bottom registration being out by .5mm or so the board is exactely what I was after and is usable as is.

There is one error that wouldn't matter at a fabricator, but as plated through holes aren't an option for home made pcb's I'll just have to make a minor repair.

This project is getting off to an ok start.

Followup... I tried to manually solder with lead free solder and what a dogs breakfast it turned out to be. I now know some of the mistakes I made, but this board is now... toast.

Ah well...

GPS Governed OCXO - Part 3

2014-08-15T02:37:00.000-07:00

I bought a Navman Jupiter Tu60 GPS module for this project. I actually paid a little more than the bare module for the Development board because, hey, its got to help get this project happening... hasn't it ?

The Jupiter T series GPS modules are specifically designed for timing applications, that is for generating high precision timing signals as opposed to tracking its position as it moves around, and the output of this module includes the 1PPS and 10KHz signals needed for this solution.

So I faithfully provide the indicated 12v power, plug in a serial cable, and... nothing...

I probe around and noted the 1PPS and 10KHz outputs in spite of my not having connected an antenna (apparently normal) but note an odd 220Khz signal on the TXD pin of the dev board. I spent a lot of time probing around and fighting with software drivers before giving in, this thing wasn't going to work at all, then around 1am I git the snits and went to bed.

Tonight I tried a different track.

First I probed the outputs of the gps module and noted a sine noisy wave on most of the modules output pins, that shouldn't be there given the module runs at CMOS TTL Levels.

So I removed the dev board and wired up a quick adapter on prototype board so I could use one of my FTDI cables. A few minutes later I have a display in Tac32 and the module is sending data with the following Receiver ID:

@@Cj

COPYRIGHT 1995-2004 NAVMAN LTD

SFTW P/N # 0000
SOFTWARE VER # 93
SOFTWARE REV # 07
SOFTWARE DATE 01/16/2004
MODEL # R01
HDWR P/N # TU60-D125
SERIAL # 407144753
MANUFACTUR DATE 401/22070
OPTIONS LIST 5843

So the module works and the dev board is a dud. In this case its not a biggy as the TTL levels are more useful to me anyway, although I will need to design and make another PCB to host it and a suitable regulator.

At this stage I'm *really* happy I have the Rigol DSO as I would have struggled to find the problem without it. I may probe the dev board to work out what's going on, at this stage that's just another case of Yak Shaving.

The next challenge will be working out how to initialise the thing as it does nothing until the software (tac32) initialises it. I want to be able to process the gps data via a microprocessor for display so this won't be a case of set and forget.

GPS Governed OCXO (aka 10MHz gps time reference) - part 2

2014-08-13T02:41:00.002-07:00

find part 1 here

In the last post I mentioned looking at using a microprocessor to intercede in the event the GPS signal was lost. I'm interested in continuing in this direction as a microprocessor would also allow me to add some nice extra's such as an ntp host and lcd display for the system status.

Most of the projects I've build previously were based around the ATMega328p, however the ADC/DAC 8 bit resolution (0.0048v) would be an issue for this project as we will need a more precise voltage sample and hold mechanism.

I considered looking at the Cortex M3/s with the 12 bit DAC/ADC for 0.001v resolution, but that processor is massively over specced and unnecessary for this solution. (http://www.atmel.com/devices/sam3x8e.aspx)

One alternative is to stick with the ATMega and use an external 12 bit DAC (MCP4725) and ADC (MCP3202). The above CPU is used in the Arduino Due and (I believe) pixhawk board so theres a lot of open source support out there.

For that matter this could be a good use for one of the many raspberry pi's or beagle bones I have sitting in a drawer. I'm still working on this, however I have decided to split the various components of this build in to separate boards:

PLL/Oscillator Board. The important bits here ;) Essentially identical to the jrmiller design using a type 1 PLL to drive the oscillator VCO. the OXCO I'm using is the Isotemp OXCO 131 Series where the VCO (nominally) ranges up to 5v. If you want to buy a solution please go to mr miller's site. The schematic and board previews are shown here for interest sake alone.

Low pass filter board. The LPF will be used to convert the square wave generated on the PLL board into a nice clean sine wave for those occasions it will be useful. While I haven't designed it yet there really isn't much to it, I'll likely make this on my CNC.

Processor Board. The processor board will monitor the system, gps and correction voltage from the PLL, it will also supply the correction voltage in the event the GPS signal is lost to minimise degradation of the oscillator frequency. I may opt to use a raspberry pi or beagle bone here as it could host an ntp server and gps location fix for several ham apps I use.

Distribution Board. Optionally a distribution board including buffering to feed the output to multiple instruments... but who am I kidding, I won't have _that_ many instruments :/

Quick note.. I've updated the board so I can fabricate it on my CNC, so it won't be pretty and purple... not that it matters ;)

GPS Governed OCXO (aka 10MHz gps time reference) - part 1

2014-08-10T03:47:00.003-07:00

I'm in the process of upgrading my electronics workbench at home with bits of 'low cost' and 'used' equipment. Generally this kit is good, however in the case of frequency counters etc they are usually well outside spec on the internal frequency reference... that is they _could_ be and I would never know.

As I'm generally working on radio related projects I like to know that when I set it to a given frequency, it _really_ is that frequency. It can be difficult to do, yes you can get there roughly through comparing to similar equipment but I want something a little more... precise.

While going through my junk box I found some OCXO's (oven compensated crystal oscillator) I've picked up at an auction or field day or similar. This discovery had me digging on the web for ways to calibrate these as a reliable time source, and as it turns out a number of people have already done this and it is surprisingly simple.

I did contemplate buying a rubidium standard from Ebay, and it is tempting and I may yet do it for interest sake alone. Not 'right' now though as they have increased in popularity and cost, and ~$200 is too much for curiosity alone.

Some pages on building gps time standards:

http://www.qsl.net/zl1bpu/MICRO/SIMPLE/SimpleGPS.htm
https://blog.safaribooksonline.com/2013/11/27/gps-plus-rubidium-plus-ntp/
http://www.hanssummers.com/gpsref.html
http://www.jrmiller.demon.co.uk/projects/ministd/frqstd.htm
http://ve2zaz.net/GPS_Std/GPS_Std.htm

Theres also a nice intro to phase locked loops here which is very relevant to this project:

http://hackaday.com/2012/02/15/intro-to-phase-locked-loops/

As I've just received a nice, shiny, and amazingly featured DSO I'm also looking at projects that will help me master this little beast of an entry level DSO. I have the DS1074Z-S which means a 70Mhz dso, 4 channels, and a dual output 25MHz signal generator. So far I'm extremely happy with this purchase and the only features I would have liked that it doesn't include (yet) is a sweep function on the signal generator and a full screen display for the hardware frequency counter for when that's all I want, small details really.

The DSO has been very helpful in understanding the behaviour of the circuit:

generate 2 10KHz inputs (simulate gps + oscillator source), varying phase, frequency, etc.
monitor the inputs, the circuit output (adjustment voltage), and display the 'logical' output of the pll via the maths functions. (3 input channels, 2 output, 1 spare).
really understand the circuit and how to adapt it to suit my OCXO which requires a higher output voltage.

Anyhow back to the project.

Ultimately all that is needed for a gps discipline is:

A gps source, ideally with a 10KHz output as 1pps complicates matters.
A circuit to drop the output of the OCXO down to 10KHz for input in to the pll.
Finally, the PLL and in my case an amplifier to generate the correction voltage to feed back into the OCXO.

And it should work autonomously.

What it won't do is:

Tell me when the circuit has stabilised and locked.

It could take time to achieve the lock. For a start we have to wait for the OCXO to heat up and stabilise (~30 minutes).

maintain any kind of lock in the absence of the gps signal.

Without GPS the output of the pll will drift depending on what the GPS sends, causing the OCXO to drift accordingly.

So I want to make a small improvement to the simple PLL circuit:

when the GPS signal is available the OCXO should be disciplined.

Aka it we have a discipline available, use it.

IF for whatever reason we lose the GPS lock, the input voltage to the OCXO should remain locked at the current level.

Aka don't go nuts jut because the boss is away.

When the input voltage is locked, the only drift we should experience is due to the oscillator ageing which in this case is +-5ppb/day. (500 picoseconds/day). For my use more than sufficient.

Aka stupidly precise timing for my needs, even without the discipline, for a year or so anyway...

The circuits..

The first circuit is based directly off the Simple GPS Stabilised 10 MHz Oscillator design by James Miller G3RUH, posted above. I've designed a simple board for this purely for my own education using surface mount components. As stated this is a simple solution.

My take on the design with an opamp thrown in to bring the PLL output into the adjustment range needed for my OCXO.

The 'simple' description of this 'simple' circuit:

* The oscillator generates its 10MHz signal as a sine wave, this is converted into the digital domain via a schmitt trigger. This output square wave is buffered to the real world by the same 74AC14 chip, and is passed to a series of decade (divide by 10) counters to generate a 10KHz output.

* The 10KHz output is fed into a phase detector (XOR) alongside the 10KHz output from the GPS. The result of this is essentially a PWM where the phase of the signal is proportional to the phase discrepency between the GPS and Oscillator.

* The PWM from the XOR is filtered (low pass filter) and charges a capacitor (C6). With a 5v OCXO this would be passed directly to the VCO adjustment on the oscillator. In this case an opamp is used to boost (amplify) the signal to the 8v I need.

The circuit will constantly adjust until a lock has been achieved, in this case I would anticipate this at approximately 180 degrees out of phase (~4v at C6) right in the middle of the adjustment range for the VCXO.

So this circuit has all the control in there. From the GPS we the following:

1PPS
10KHz
GPS Lock/No Lock

From the GPS Discipline we can (potentially) provide:

10Mhz (square wave).
10Mhz (sine wave)
1Mhz (square wave)
100KHz (square wave)
10KHz (square wave)

But if we lose the GPS lock we have a problem. In the above circuit, no input from the gps results in the output from the PLL slowly dropping to a minimum which would reduce the the frequency coming out of the OCXO.

I want my version oscillator to be reasonably reliable in the absence of a gps signal so that once its set (gps lock) the oscillator will maintain the discipline up to the limits of the oscillator ageing. Theoretically I could occasionally calibrate the oscillator to the gps discipline and use it reliably within the capabilities of the oscillator until it is re calibrated.

Ideally it would always have a gps lock, but as I want the reference to be somewhat portable that isn't always guaranteed. At this stage I'm looking at either somehow latching the voltage output or introducing a microcontroller to supplement (or replace) the PLL. I'm leaning towards the microcontroller option as it would be nice to have a display or similar to display the status of the oscillator.

A simple solution would be to provide a 10 turn pot and 'preset' the hold voltage and use a relay to switch between the pll and the preset. This would limit the run down in the event of a loss of gps, but would need to be adjusted carefully to limit the loss of accuracy at that time. There would also be a period of time when the pll was resumed where the clock was unstable, not a biggy in this application. There's also the option to implement a 'sample and hold' circuit or some description.

I could be overthinking this entire solution as I can simply opt 'not' to use the oscillator if there isn't a suitable gps reference to be found.

As far as indicating the lock state, this could be as simple as monitoring the voltage in to the VCO and identifying when it has stabilised. A simple task for almost any microcrontroller.

Anyhow.. that's for the next part of this project.

Received my Rigol DS1074Z-S

2014-08-08T03:14:00.002-07:00

My home lab received a huge upgrade today thanks to the Rigol DS1074Z-S which includes the 25MHz function generator, essentially 2 pieces of kit in one which is useful given my space constraints.
Of course I couldn't resist doing the old lissajous curve for the ABC Symbol.

I've actually been putting the old Wavetech Model 3001-691 signal generator through its paces and its nice to see its spot on calibration, not bad for such an old piece of kit. The DSO copes nicely down to .5 millivolts as per the spec, it is able to display the waveforms down to .03 millivolts but the resolution is pretty poor. Otherwise its what you would expect for a 70MHz DSO, I'm happy with it.

I'm obviously still in the market for a decent frequency counter, however this will do me nicely for now until I save the pennies for a frequency counter, spectrum analyser, precision voltage source...

Pico Tracker (ballsup1) -- Gerbers are done

2014-08-06T17:38:00.001-07:00

And to my mind it looks ok. I'm sure there will be rework as this is a first for me as I've only ever made my own boards before. So exciting!

Pico tracker (ballsup1) update... ready for a design review.

2014-08-04T06:09:00.000-07:00

For the first time I can remember I actually got to enjoy a bank holiday. While I had all sorts of plans, with SWMBO unwell I spent a good part of the day working on the tracker design with some significant changes. I've created the 'shopping' list to be submitted to Digikey, if they only accepted Amex I would have placed the order.
Key design changes:

* Changed from the tps61071 to the tps61200 boost converter. Higher current sourcing ability, lower drop out on the input power. This chip also supports a 'power save' mode which will be useful in this application.

* Added support for a BMP085 barometer, more instrumentation is a good thing in this application.

* Removed the pads for selecting serial/i2c on the GPS. i2c will be sufficient and the serial port will be needed for programming and potentially supporting a TTL/Serial camera module.

* Changed the layout of the low pass filter for on the RF side of the circuit.

* Corrected the routing of the VCXO to the Si4463. I was actually hoping to get some 4063's as the RX stage is wasted, unfortunately the usual suppliers don't have this in stock. As it is I can only get a couple of the VCXO's for now. Some of the changes I've made will allow for some reorganisation of the board as it is... but I have to stop somewhere!

As a consequence of the changes the board is a few mm longer than it was previously. This is essentially the first prototype so there is every chance I'll only ever make one of these before moving to a more compact solution (more layers... yay).

Now for some critical reviews and getting the boards made.

And for reference, the repo:

https://github.com/agronaught/Wars-Tracker

Almost Done... Picio Tracker (BallsUP1)

2014-07-31T21:03:00.002-07:00

Nearly there!

The design has been modified to use a JST connector for the serial connection which is used for configuration. I've also been doing spot checks on pad sizes, and with the exception of the inductors which need to be ordered its looking good. The pads are larger than they need to be by design so I can get in there with a solder iron, although solder irons and 0402's could be... tricky.

Pictured is the final size next to a AA battery for scale.

The capacitor, resistor and LED pads are right as the should be. The ATMega328P lines up nicely as does the GPS.

The GPS Antenna needs a little work, while it could be hand soldered in place I don't think it would reflow as it is so some adjustments to be done.

I'm tempted to send this off to manufacture before I get all the parts and risk the pad sizes, I'm a little cautious as inductor sizes can vary considerably.

Git repo: https://github.com/agronaught/Wars-Tracker

Updated tracker design

2014-07-28T05:30:00.002-07:00

Unfortunately I'm still waiting on parts for the cc430 design so I can verify the pad sizes... getting more than a little frustrated actually as the processor (cc430) is proving to be allusive.

In the meantime working another small tracker so I can send some balloons back down to Andy (VK3YT) who's been an absolute inspiration with his launches. At this point my design will be a lot heavier than his, but its a starting point that will allow me to work on the software while the design matures a little ;)

I may need to either licence eagle to go three layers or migrate to Kikad. My open source roots are calling me so a change of software may be in order.

This design is based around the ever popular ATMega328p using the Si4463 transceiver for its broad frequency range. This is far from an original design, building on similar open hardware designs so credit needs to be given where credit is due.

My references:
The Pecan Femto by DL7AD
The Pecan Pico 4 by KT5TK

Thanks for sharing gents, hopefully this software guy can give a little back.

Key notes:

* ATMega328p
* uBlox MAX-7C GPS
* Si4063/Si4463. I would prefer the 4063, but the 4463 is actually available...
* FVXO-HC52BR-27 VCXO
* TPS61071 DC-DC Boost Converter.

To do:

* Reduce the size
* Find a 0.05" (0.1mm) pitch header to replace the 1mm header shown below.
* Add some 'optional' sensors.
* Add an i2c eeprom if additional storage/reference tables are needed.
* possibly go 3 layer to aid in reducing the size.

The schematic

The board, which I'm not even remotely happy with at the moment:

So still on it, although running behind my schedule. A smaller footprint smd female header on the back of the board would get rid of the ugly breakaway header currently shown and there is space for it.

Anyhow, time for bed...