VE9QRP

Here's a picture of the in-progress Eagle schematic view for Satpack, my altoids-sized, atmega-driven satellite tracking dongle for the FT-817 (or TH-D7A, or whatever). The 20-pin SOIC chip is meant to be a DS3231 or DS3235 Realtime clock. If someone writes a library to access the FRAM on the DS3235, I'll forego a EEPROM chip; likely I'll put one on the I2C bus just to be sure.

The conversation on Ontario Bill 118 continues over at the excellent RACblog .   VA3QF suggests this paper, which in turn makes use of the Jabra A210, a bluetooth cellphone adapter. That device seem to be on the end of its run, but we can likely find others. I consider the audio link side of the equation pretty solved. I think there are two issues that need to be dealt with. An alternative PTT scheme. VOX just isn't always the way to go. Could a flex sensor be used to pick up a unique body gesture that is not considered unsafe? Such as a shrug or a flexed finger?  Automatic repeater handoff on long trips. As I understand the regulations, it would not be permitted to change frequencies, so unless one is willing to pull over each time he or she switches repeaters, a trip from, say Toronto to Kingston could lose contact pretty quickly as the Toronto repeater is lost. A combination of a micro-controller, GPS, CAT radio control and a small database of repeaters could ma...

Ontario's new distracted driving legislation apparently does not have the exemption for two-way radios that many similar laws include. Indeed, at first glance, it seems that the situation in Ontario is far worse than south of the US border. In my opinion, though, the battle over distracted driving is one that the international amateur radio fraternity probably can't win and in some circumstances ought not to fight. Instead, we should use the Ontario situation to do what we do best: look for technical solutions to this problem and highlight our ingenuity in the face of changing social norms.

Here's a video introducing my Arduino port of Plan13. If you know about Arduino and about satellites, you might want to skip forward to 1:30 or so. If this doesn't appear well embedded in blogspot, here' the link to the blip.tv site. There's a youtube video as well, but the resolution is so poor that you can't read the screen text.

In a previous entry, I mentioned how accurate Plan13 is. Recently, I collected side-by-side data from plan-13 and the respected Predict program and compared their results for satellite latitude and longitude. A day's worth of data regarding CO-57, a low and fast-moving satellite, resulted in a worst-case difference of 39.5 km between plan-13's predicted latitude and longitude and that of Predict. On average, the difference was 14.5 km. 

Before beginning a simple robot project, I mocked this design up in Google Sketchup using components available in the Google 3D Warehouse. The models of the caster, motor pack and wheels for those I had already bought were luckily already in the Warehouse. I added the models of the various layers and, most importantly, of the PCBs I had already made for the picaxe-based CPU and a speakjet board.

The short version of this post is as follows: the 'C' versions of Plan13 all share a bug that make the algorithm unable reliably to track HEO and GEO satellites. To fix this bug find the part of the code that reads something like this: /* Solve M = EA - EC * sin(EA) for EA given M, by Newton's method */ EA = M; /* Initail solution */ do { C = cos(EA); S = sin(EA); DNOM = 1.0 - EC * C; D = (EA - EC * S - M) / DNOM; /* Change EA to better resolution */ EA = EA - D; /* by this amount until converged */ } while (abs(D) > 1.0E-5); and replace abs with fabs . (If you are using the original C port by Edson Pereira this is line 501.) The more in-depth version of the story follows.