No major problems with the orienteering - perhaps a sign of too
easy slow route-choices?
#1 first down to the path, then up to the control again. OK.
#2 same approach, a with bit of standing around inside the control circle
#3 OKish to the lake, then easy along the path up to the control
#4 The plan was to find the path north of the line, but execution is not so good, drifting around until the road. From the road the control was easy along the ditch.
#6 no good plan for how to find the control in an empty area of the map. The different swamps and white/light-green forest look much the same in reality.
#7 biggest mistake. OK feeling and on the map on the hill before the control, then within the control circle slightly wrong and up too high on the hill, circling back until the ditch before finding the control. No good with +6 minutes lost to the leader.
#8 - Finish. OK.
A bit more speed and no stupid mistakes will make for a top-10 next week... 🙂
A fairly late orienteering season opening this year.
#1, #2, #3 fairly ok. Then slow on the side of the hill towards #4 - right of the line on the flatter top of the hill would be better. Down from #4 in an S-curve to the road. From the road no good plan through the green to #5.
#6-#7-#8 ok before checking out a false flag just before #9.
The ugliest squiggle is at #13 where I fail to see the 90-degree turn over the swamp that leads to the control-circle and instead cross the swamp almost straight north (90-ish degrees off course) and stop just in the to see a glimpse of #13 through the open flat woods. Looking at the compass before crossing the swamp would have been good.
RF-multiplexer v2 board in enclosure, controlled by Arduino Due with Ethernet Shield. SATA-cable for 4 SPI-lines (SI, SO, SCLK, CS).
When issuing commands to change state as fast as possible this combination seems to do a state-change in about 45 milliseconds - this is not verified on the RF-side (didn't measure that there is actual RF contact made/broken in those 45 ms).
Version two of the RF Multiplexer adds more relays to the 8 pcs HF3 I was using in the first attempt. The added relays keep the RF-path from the selected input to the COM-output as clean as possible with no unterminated branches or stubs. The cost is anothe 7 relays with associated darlington-drivers and control-logic.
Next test is to see if there is any measurable change to the rise-time of a fast pulse-edge, e.g. from a distribution amplifier.
This is the fourth version of an interface board to Small Form Factor Pluggable optical transcievers (SFPs) with a bandwidth of >500 MHz. These are useful for various time/frequency experiments, with a measured frequency stability of <1e-13 @ 1s (in 0.5 or 5 Hz bandwidth) - perhaps slightly depending on what SFP is used. The SFP allows sending the signal along a single-mode fiber for 1-100 km easily.
ADT2-1T converts to and from differential signals while LMH6702 op-amps provide 3 dB gain. There are parallel outputs on the RX pins. The current-draw on +3V3 by the SFP is quite high - usually requiring heat-sinking on the voltage-regulator
KiCad files available on request.
It seems that all programs fix the lat/lon output. However both gLAB and RTKLIB leave the height as a variable parameter. Interestingly it seems there is some peak at the end of the PTBG data and gLAB compensates by raising the height while RTKLIB compensates by raising the clock value.
And now an entry in the "Plan to throw one away" section.
RF Multiplexer, 8 inputs, 1 output, BNC-connectors, TE HF3 relays specified to 3 GHz, an ULN2803A to pull the relay-coil, and an SPI I/O expander to drive the ULN - should be easy - right?
Well no, PCB trace-geometry does strange things beyond VHF. I clearly don't grok UHF very well.
Onward towards version 2! (any thoughts and advice on simulation or trace-geometry optimizers appreciated!)