Cars manufactured about 10 years ago often do not provide bluetooth audio support. Here I describe a proven setup with bluetooth (A2DP and HFP) for an Audi with the built-in radio “Concert 2” and the built-in hands-free system. I use two different audio devices for music (A2DP) and telephone (HFP). For recent firmware versions (iOS 7.x) of the iPhone it is possible to use multiple bluetooth audio devices.
HFP: I have chosen not to replace the built-in hands-free system, because the microphone position and the active noise canceling is way much better in this (old!) system, than in recent radios (i.e. JVC KW-AV60BT, SONY MEX-N500BT). The iPhone adapter charges the phone and connects to the roof-mount antenna inductively.
A2DP: The Concert 2 radio has a CD changer interface, which is used by the GBL3AU2 for providing A2DP (and HFP optionally). This way the original radio is preserved. Audio works very nicely and changing songs via steering wheel, too. For all other functions I use my iPhone. This is not a disadvantage for me, because even though other radios mentioned above claim to provide “full” iPhone support, they do not in reality (Errors in title names, errors in album names, wrong playlists, no covers, …).
I think the dension gateway is an elegant solution for a minimal invasive upgrade to bluetooth audio. The gateway is available for more cars.
As of today bandplan information for amateur radio is accessible in form of various spreadsheets, PDFs or even in Wikipedia. Of course this differs from country to country. Depending on the source, the bandplan may be outdated and it can be challenging to find a valid source for up-to-date information. While it is possible to find bandplan authoritative information on bandplan usage for the three different IARU regions, the best-practices for the member countries are even more difficult to find. In short: the information is difficult to find, exists in various formats and is not at hand when you really need it.
For my FT 817 remote control project I was in need of a digital bandplan for my C source code. Instead of hacking the information into the corresponding C structures I chose a different approach: I created a structured XML file with the bandplan information and used XSLT scripts to generate the corresponding C structures from the XML file:
Using (XSLT) scripts this information can be converted to C source code:
Well I did not stop there: I implemented capabilities for handling different regions within the frequency bands, countries and licenses. In the XML files this looks like this:
In addition to the obvious bandplan informations it was also helpful to create channels on particular frequencies. These channels can contain a name or a mode information, i.e. for switching the TRX automatically.
During the implementation I realized, that all entries should have some generic information, i.e. the author of the entry, a version number, a timestamp and a reference. The references (i.e. HTML, PDF or spreadsheets) can be downloaded within the framework I have created, stored to the git repository and checked for updates using MD5 sums. Checking the bandplans for possible changes is easily done now using the toplevel makefile:
$ make check_references
It is possible to check the syntax of all bandplans using the top level makefile:
$ make xmltest
What can we do with this structured XML documents? Obviously I have used it for my Arduino project. Using this information source it is easy to create HTML bandplans, PDFs or structures in the programming language of your flavour for further work.
$ make html
|Frequency (MHz)||Bandwidth (kHz)||Mode||License||Reference||Comment|
|3.500 – 3.580||2.700||
|3.500 – 3.510||0.200||CW||
|3.510 – 3.560||0.200||CW||
|3.560 – 3.580||0.200||CW||
|3.580 – 3.590||0.500||Digital||
|DE01||small bandwidth digital modes|
|3.590 – 3.600||0.500||Digital||
|DE01||small bandwidth digital modes, automatic digital stations|
|3.600 – 3.620||2.700||All||
|3.620 – 3.650||2.700||All||
|3.650 – 3.700||2.700||All||
|3.700 – 3.800||2.700||All||
|3.760||DE01||Emergency Region 1|
|3.775 – 3.800||2.700||All||
Now there is a structured document framework, which can handle all bandplan information. So far I have implemented US and german bandplans. We now have one source for all the information we need. The XML bandplan project is a building block for your future ideas and projects. Feel free to contact me and contribute ideas, converters, updates and bandplan content.
There are three morse decoders in the App Store. Same test case for all of them: “CQ CQ CQ DE DG
D6FL DG6FL K” from memory of my palm paddle with 20wpm.
- MorseDecoder (HotPaw Productions)
Seems to work
- MorseDec (Luca Facchinetti)
Room for improvement
- Morsepad (Black Cat Systems)
Does not work at all
In contrast to claims in the web (i.e. M. Kofler: Sackgasse LaTeX?) it is possible to create ebooks from LaTeX sources easily even with sophisticated formulas and custom stylesheets. Using calibre and tex4ht I was able to provide an ePub of my PhD thesis: Atomistische Simulation von Nanoindentation. The resulting output looks quite impressive (minor defects when it comes to image boundaries or subscripts in text blocks). For comparison the original PDF.
Recently the Raspberry Pi (Raspi) has gained much interest in the Ham Radio community. One interesting things is: the I/O pins provide access to a clock signal (GPCLK0) and it is possible to modulate this clock signal via software. This has motivated Guido Ten Dolle (PE1NZZ) to implement a WSPR transmitter and to publish the sources under GPL. Within the last days I have made some minor modifications to the WsprryPi sources, built a 30m QRP filter using the ugly method and connected everything to my doublet antenna.
|Raspi as WSPR Transmitter|
Immediately my 10mW have been received in 743km distance by G6HUI (WSPR Spots):
|7869km with 10mW|
Information on how to do this yourself can be found in the WsprryPi repository.
A small reminder for all the options:
mount.cifs //184.108.40.206/public /mnt/public -o user=myusername,password=mypassword,nounix,sec=ntlmssp,noperm,rw
Time machine can keep local snapshots. While this feature is useful if you travel and don’t have access to your Time Capsule, the local snapshots can consume a lot of the local disk space in /.MobileBackups. There is a complex Removal Algorithm for old local snapshots based on the remaining free disk space.
To find out how much space your local snapshots consume (Local Snapshots):
- Apple-Logo → About This Mac → Further Information → Storage: Backup == Local Snapshot Space
- Alternatively from commandline:
test -d /.MobileBackups && du -hcs /.MobileBackups
It is useful to control the behavior of the local snapshots yourself (Controlling Local Snapshots) using tmutil disablelocal and tmutil enablelocal.