16 Megapixel Outdoor Network Camera on the Cheap

I always wanted to have a network camera that provides a good image quality but does not cost a fortune. Modern network cameras that have a resolution of 4K cost upwards of 4000$. There are some cheap cameras that actually cost less, but their image quality is most often not that great.

A couple months ago I made a great deal on some second-hand Nikon Coolpix L31 cameras. I paid 15$ for two pieces of them, because one had a crack in the display and the other one had a broken battery lid.

My idea was to connect the cameras to a Raspberry PI and use gphoto2 to take pictures and send them back to a sever over the network. The only thing I needed was a outdoor weather-proof enclosure. I found a suitable one at a local hardware store.

The enclosure I used is actually the body of an halogen spotlight used on construction sites. It is perfectly suited for this purpose as it is IP44 protected and has a glass front through which the camera can take pictures without being exposed to the elements. But the best thing is the price as it costs only 12$ which is an absolutely amazing price for such an enclosure.

Before I go into details how I built the camera, here are some sample shots of it during the night and in daylight.

AFU_Zimmer_1463270823day_good_AFU_Zimmer_1463473863
If you pay close attention to the picture during the night you might notice the orange reflection on the top. This is because I forgot to cover a LED of the Raspberry Pi with black electrical tape. I will fix this soon 🙂

When I started to build this I first removed the guts of the lamp and installed a 3D printed mount for the camera. I designed the mount in OpenScad and you can find my the files for the print on my Thingiverse account here (actually I currently am not able to verify the mail address of my Thingiverse account as I only get an HTTP 404 error). The slots fit perfectly for a camera screw.

I used the following camera screws: Link to Amazon

DSC_0465

The camera holder is attached by the two screws at the bottom.

DSC_0442

To mount the Raspberry PI I used nylon screws with a nut used as a spacer.

DSC_0476

In the back of the enclosure a plate is mounted and on that plate the Raspberry PI is screwed on.

DSC_0477

I had to cut away some of the plastic of the micro USB connector because it was too long and touched the case.

DSC_0479

After the PI was mounted I inserted the camera screw into the camera holder.

DSC_0481

Then the camera was screwed on and the network cable was fed through the hole and stripped.

DSC_0484

As the camera needs a 3 volt supply, I build one with an LM350 which is quiet overkill. It does not need the current supply capability of 3 amperes. In this picture I had not added the capacitors which should be used with the linear regulator. On the bottom is a DCDC converter from ebay.

DSC_0486

The network cable is also used for power according to the power over ethernet “proprietary” standard that uses the four unused wires of an ethernet cord and provides power and 100 Mbit connectivity.

You can find the appropriate wiring here.

The four power wires were attached to the DC DC converter which was set to provide 5 volts for the PI. I attached the USB cord of the PI to the output of the DC DC converter.
From the 5 volt output two wires were attached to the input of the linear regulator. The output of this regulator is attached to wires that are soldered on to the battery tabs of the camera.

In this picture you can also see the USB cable used to connect the camera and the PI.

DSC_0487

The finished assembly with the voltage regulators on the right.

DSC_0508

After completing the assembly of the camera enclosure I attached the ethernet cord to a power over ethernet switch and tested the connection to the PI.

DSC_0510  DSC_0528

The power over ethernet switch is a modified cheap ethernet switch to which I added a DC DC converter and connected the appropriate wires for power between the ethernet plugs.

DSC_0534

 

Now the camera is operating for some weeks and I have not seen any problems due to rain. The only thing to pay attention to is to cover every LED of the Raspberry Pi so that your night pictures do not show ugly reflections from the glass.

In part 2 of this post I will provide a small description howto compile gphoto2 and install the necessary scripts on the PI to regularly take pictures.
You can follow me on Twitter so that you do not miss the second part.

How to link two Svxlink Repeaters

The amateur radio community has installed some Tetra repeaters in Vienna. Currently there are three repeaters active that should cover nearly the whole city. These repeaters operate in the so called DMO mode, which is actually a operation mode for direct radio to radio and radio-repeater-radio communication. Devices that support this mode are relatively cheap contrary to the TMO mode that is used in the Tetra deployments of emergency services, because the DMO mode does not need base-stations and other backend services at the cost of the lack of interconnect between the repeaters. Therefore there is no possibility to talk with people that are connected to a different repeater than you are.

We solved this by connecting the repeaters over the HAMNET network by using SvxLink nodes and USB soundcards that are connected to Tetra radios.

The three repeaters deployed in Vienna are:

  • OE1XTW – Arsenal radio tower
  • OE1XAR – Bisamberg
  • OE1X?? – Vienna, 14. district

I am member of the “A1 Amateurfunk Club” which maintains the OE1XTW repeater on the Arsenal radio tower. As I already mentioned in a previous article, we have an Echolink access to the repeater. This was set-up using a Raspberry Pi and a custom USB sound-card that has an output to activate the transmitter of the Tetra radio. The software that is used for the Echolink connectivity is SvxLink.

 

OE1XTW (picture by OE1WUW)
OE1XTW (picture by OE1WUW)

 

Tetra radio used for OE1XTW
Tetra radio used for OE1XTW
USB Soundcard used to connect to the Tetra radios
USB Soundcard used to connect to the Tetra radios
Propagation plot of OE1XTW
Propagation plot of OE1XTW

The other two repeaters had no EchoLink access until recently I built the link between OE1XTW and OE1XAR with the kind help and donation of OE1KBC (Kurt).

Our current SvxLink setup for OE1XTW used a SimplexLogic in the configuration as the uplink to the repeater is done by another Tetra device and not directly on the repeater, because unfortunately the used repeater (a Cleartone CM5000) does not output any audio signals on the interface on the back while it is configured in repeater-mode.

The configuration of the SvxLink node for OE1XTW before configuring the link to OE1XAR (svxlink.conf):

###############################################################################
#
# Configuration file for the SvxLink server #
#
###############################################################################

[GLOBAL]
MODULE_PATH=/usr/local/lib/svxlink
LOGICS=SimplexLogic
CFG_DIR=svxlink.d
TIMESTAMP_FORMAT="%c"
CARD_SAMPLE_RATE=48000

[SimplexLogic]
TYPE=Simplex
RX=Rx1
TX=Tx1
MODULES=ModuleEchoLink
CALLSIGN="OE1XTW-R"
SHORT_IDENT_INTERVAL=15
LONG_IDENT_INTERVAL=30
EVENT_HANDLER=/usr/local/share/svxlink/events.tcl
DEFAULT_LANG=en_US
MACROS=Macros
FX_GAIN_NORMAL=-7
FX_GAIN_LOW=-12
MUTE_TX_ON_RX=1

[Macros]
1=EchoLink:9999#
9=Parrot:0123456789#
03400=EchoLink:9999#

[Rx1]
TYPE=Local
AUDIO_DEV=alsa:plughw:1
AUDIO_CHANNEL=0
SQL_DET=VOX
SQL_START_DELAY=0
SQL_DELAY=0
SQL_HANGTIME=2000
SQL_EXTENDED_HANGTIME=1000
SQL_TIMEOUT=600
VOX_FILTER_DEPTH=20
VOX_THRESH=400
SIGLEV_SLOPE=1
SIGLEV_OFFSET=0
SIGLEV_OPEN_THRESH=30
SIGLEV_CLOSE_THRESH=10
DEEMPHASIS=0
SQL_TAIL_ELIM=300
PEAK_METER=1

[Tx1]
TYPE=Local
AUDIO_DEV=alsa:plughw:1
AUDIO_CHANNEL=0
PTT_TYPE=Hidraw
HID_DEVICE=/dev/hidraw0
HID_PTT_PIN=GPIO1
TIMEOUT=300
TX_DELAY=0
PREEMPHASIS=0

This uses the alsa device 1 (which is the usb soundcard on the Raspberry Pi) as receive and transmit channel to the radio and /dev/hidraw0 (which is the HID endpoint of the soundcard) as PTT control.

To configure the link to OE1XAR I first setup another Raspberry PI which has another USB sound-card attached and is connected to a CM5000 Tetra radio at OE1XAR.

The remote connection is configured by changing the file remotetrx.conf on the new Raspberry PI with svxlink already installed that contains the following:

###############################################################################
#
# Configuration file for the RemoteTrx application. A remote transceiver
# for the SvxLink server system.
#
###############################################################################

[GLOBAL]
TRXS=NetUplinkTrx
TIMESTAMP_FORMAT="%c"
CARD_SAMPLE_RATE=48000
CARD_CHANNELS=1

[NetUplinkTrx]
TYPE=Net
RX=Rx1
TX=Tx1
LISTEN_PORT=5210
AUTH_KEY="--Link Key--"

[Rx1]
TYPE=Local
AUDIO_DEV=alsa:hw:CARD=Set,DEV=0
AUDIO_CHANNEL=0
SQL_DET=VOX
SQL_START_DELAY=0
SQL_DELAY=0
SQL_HANGTIME=2000
SQL_EXTENDED_HANGTIME=1000
SQL_TIMEOUT=800
VOX_FILTER_DEPTH=20
VOX_THRESH=400
SIGLEV_SLOPE=1
SIGLEV_OFFSET=0
SIGLEV_OPEN_THRESH=30
SIGLEV_CLOSE_THRESH=10
DEEMPHASIS=0
SQL_TAIL_ELIM=300
PEAK_METER=1

[Tx1]
TYPE=Local
CARD_CHANNELS=2
AUDIO_DEV=alsa:plughw:1
AUDIO_CHANNEL=0
PTT_TYPE=Hidraw
HID_DEVICE=/dev/hidraw0
HID_PTT_PIN=GPIO1
TIMEOUT=300
TX_DELAY=0
PREEMPHASIS=1
DTMF_TONE_LENGTH=100
DTMF_TONE_SPACING=50
DTMF_DIGIT_PWR=-15

We can now establish the connection to the remote node by adding a second SimplexLogic to the “master” SvxLink node. I called the new logic “SimplexLogicBisamberg”.

[SimplexLogicBisamberg]
TYPE=Simplex
RX=NetRx
TX=NetTx
CALLSIGN="OE1XAR-R"
SHORT_IDENT_INTERVAL=15
LONG_IDENT_INTERVAL=30
EVENT_HANDLER=/usr/local/share/svxlink/events.tcl
DEFAULT_LANG=en_US
MACROS=Macros
FX_GAIN_NORMAL=-7
FX_GAIN_LOW=-12
MUTE_TX_ON_RX=1

The new logic has to be added to LOGICS in the GLOBAL section:

[GLOBAL]
MODULE_PATH=/usr/local/lib/svxlink
LOGICS=SimplexLogic,SimplexLogicBisamberg
CFG_DIR=svxlink.d
TIMESTAMP_FORMAT="%c"
CARD_SAMPLE_RATE=48000

This alone is not enough as SvxLink will now complain that the file SimplexLogicBisamberg is not found, which can be fixed by copying the following files:

cd /usr/local/share/svxlink/
cp events.d/SimplexLogic.tcl events.d/SimplexLogicBisamberg.tcl
cp SimplexLogic.tcl SimplexLogicBisamberg.tcl

After that you have to open the files and change SimplexLogic to SimplexLogicBisamberg:

Start of file /usr/local/share/svxlink/SimplexLogicBisamberg.tcl:

###############################################################################
#
# SimplexLogic event handlers
#
###############################################################################

#
# This is the namespace in which all functions below will exist. The name
# must match the corresponding section "[SimplexLogic]" in the configuration
# file. The name may be changed but it must be changed in both places.
#
namespace eval SimplexLogicBisamberg {

Start of file /usr/local/share/svxlink/events.d/SimplexLogicBisamberg.tcl:

###############################################################################
#
# SimplexLogic event handlers
#
###############################################################################

#
# This is the namespace in which all functions below will exist. The name
# must match the corresponding section "[SimplexLogic]" in the configuration
# file. The name may be changed but it must be changed in both places.
#
namespace eval SimplexLogicBisamberg {

Now we can configured the required NetRx and NetTx sections in svxlink.conf:

[NetRx]
TYPE=Net
HOST=--OE1XAR Raspberry PI IP Address--
TCP_PORT=5210
AUTH_KEY="--LINK KEY--"
CODEC=S16

[NetTx]
TYPE=Net
HOST=--OE1XAR Raspberry PI IP Address--
TCP_PORT=5210
AUTH_KEY="--LINK KEY--"
CODEC=S16

We used the S16 codec, because there was enough bandwidth available. If you find yourself in a scenario where the connection bandwidth between the two SvxLink nodes is limited, take a look at the SPEEX codec.

The only thing missing now is the link between the two logics. This can be configured by adding the following section to the svxlink.conf file:

[LinkToBisamberg]
CONNECT_LOGICS=SimplexLogic:99:OE1XTW,SimplexLogicBisamberg:98:OE1XAR
DEFAULT_ACTIVE=1
OPTIONS=DEFAULT_CONNECT,NO_DISCONNECT
TIMEOUT=300
AUTOACTIVATE_ON_SQL=SimplexLogicBisamberg

Actually the numbers 99 and 98 are the commands used to enable the links, but they are unused in this configuration as the links are configured to be active all the time and cannot be disconnected.

The new link has to be added to the GLOBAL section which should look like this afterwards:

[GLOBAL]
MODULE_PATH=/usr/local/lib/svxlink
LOGICS=SimplexLogic,SimplexLogicBisamberg
CFG_DIR=svxlink.d
TIMESTAMP_FORMAT="%c"
CARD_SAMPLE_RATE=48000
LINKS=LinkToBisamberg

If you want to use this config, please do not forget to change the link key and IP address of the remote node.

In this configuration EchoLink access is only possible to the main SvxLink node but if someone connects to it, audio will be sent to both repeaters and audio from both repeaters will be forwarded to the connected EchoLink user.

Bricked TrekStor wintron 7.0

A couple of weeks ago I bought a small 7” tablet with Windows 10 pre-installed, and because I use Linux everywhere, I tried to install Ubuntu on the tablet. Actually I wanted to install it to the micro-SD card and try things out first.
Turns out that there is a bug in Baytrail Atom processors which prevents the UHS-I SD card from being accessed in DDR50 mode. Unfortunately this makes Ubuntu very slow.

DSC_0368 DSC_0369

Even if the default Bios settings disable the high-speed mode, I decided to try to enable DDR50 in spite of the known problems, but I had no success. Linux just reported MMC read errors. After looking around the internet I found some kernel patches that should improve the reliability of the SDIO interface and fix some race conditions with the C-sleep states of the CPU while accessing the MMC card. I really hoped that these patches will help and so I compiled a new kernel for the tablet, but this did not fix the problem.

(You can find those patches at the repository of the wifi/bluetooth card https://github.com/hadess/rtl8723bs)

And here comes my mistake… During some fiddling around in the BIOS settings I accidentally disabled the DMA controller, which is not a smart idea. The result was, that the tablet did not boot anymore and me being a bit frustrated. On a desktop PC I would in this case simply pop-out the BIOS battery on the mainboard, but there is no BIOS battery in this tablet and also the BIOS stores the settings on non-volatile memory, which is in this case a SPI flash chip. On traditional PCs BIOS settings are often stored in battery-backed RAM which can be cleared when the battery is removed. On modern mainboards they are stored in NVRAM but there is a CMOS clear jumper which has the same effect as removing the battery on older PCs. So this was my first idea. Maybe the manufacturer has designed some test-pads onto the PCB that can be used to reset the bios settings.

To check my assumption, I had to open the tablet. This is fairly easy by just using a thin piece of plastic that can slide in the gap between the two halves of the case.

DSC_0372

After the case was opened, I was greeted by the mainboard (this was a very hassle-free disassembly when compared to modern tablets in the higher price-segment), but unfortunately I was unable to find any test-points for resetting the BIOS. I just found an UART port and test-pads for the factory programming of the SPI flash.

DSC_0375 DSC_0381

There is a metal shielding can, which also seems to be used as a heat-sink for the Intel Atom Z3735G processor and the AXP288 voltage regulator. The SPI flash is located on the left of the processor.

DSC_0391DSC_0392

The SPI flash is a 25LQ64 chip. Although I did not find a datasheet, the chip is most likely a 1.8V only chip, because I measured VCC to be 1.8V.

So I decided, that I will have to reflash the BIOS. There is an “Image Update Image” avaliable on the support website of the tablet, which is a 4.8 GB big ZIP file named V1.1.4_WI71C.JGBMRBA05.zip. This file contains the file images/BIOS/TREK.G.WI71C.JGBMRBA05.ROM, which is in fact a complete image of the BIOS flash.

alex@laptop:~$ ls -l TREK.G.WI71C.JGBMRBA05.ROM 
-rw-rw-r-- 1 alex alex 8388608 Mai 10 00:46 TREK.G.WI71C.JGBMRBA05.ROM

alex@laptop:~$ md5sum TREK.G.WI71C.JGBMRBA05.ROM 
4117f6f5e1643774710c7251329d6fa0  TREK.G.WI71C.JGBMRBA05.ROM

Also it would be quite interesting to unpack the bios image, which seems to be LZMA compressed. Binwalk reports lots of Portable Executables, which most likely are the UEFI binaries.

alex@laptop:~$ binwalk TREK.G.WI71C.JGBMRBA05.ROM 

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
5406926       0x5280CE        Certificate in DER format (x509 v3), header length: 4, sequence length: 885
5407927       0x5284B7        Certificate in DER format (x509 v3), header length: 4, sequence length: 1512
5409553       0x528B11        Certificate in DER format (x509 v3), header length: 4, sequence length: 1495
5411096       0x529118        Certificate in DER format (x509 v3), header length: 4, sequence length: 1552
5412696       0x529758        Certificate in DER format (x509 v3), header length: 4, sequence length: 885
5836920       0x591078        LZMA compressed data, properties: 0x5D, dictionary size: 16777216 bytes, uncompressed size: 4034576 bytes
7799072       0x770120        Microsoft executable, portable (PE)
7800640       0x770740        Microsoft executable, portable (PE)
7801184       0x770960        SHA256 hash constants, little endian
7804751       0x77174F        mcrypt 2.2 encrypted data, algorithm: blowfish-448, mode: CBC, keymode: 8bit
7828288       0x777340        Microsoft executable, portable (PE)
7831360       0x777F40        Microsoft executable, portable (PE)
7832352       0x778320        Microsoft executable, portable (PE)
7833047       0x7785D7        mcrypt 2.2 encrypted data, algorithm: blowfish-448, mode: CBC, keymode: 8bit
7838784       0x779C40        Microsoft executable, portable (PE)
7839408       0x779EB0        UEFI PI firmware volume
7843616       0x77AF20        Microsoft executable, portable (PE)
7865664       0x780540        Microsoft executable, portable (PE)
7868224       0x780F40        Microsoft executable, portable (PE)
7872064       0x781E40        Microsoft executable, portable (PE)
7873696       0x7824A0        Microsoft executable, portable (PE)
7874624       0x782840        Microsoft executable, portable (PE)
7876320       0x782EE0        Microsoft executable, portable (PE)
7878208       0x783640        Microsoft executable, portable (PE)
7881728       0x784400        Microsoft executable, portable (PE)
7887904       0x785C20        Microsoft executable, portable (PE)
7893984       0x7873E0        Microsoft executable, portable (PE)
8127040       0x7C0240        Microsoft executable, portable (PE)
8136768       0x7C2840        Microsoft executable, portable (PE)
8138336       0x7C2E60        Microsoft executable, portable (PE)
8139808       0x7C3420        Microsoft executable, portable (PE)
8146336       0x7C4DA0        Microsoft executable, portable (PE)
8158528       0x7C7D40        Microsoft executable, portable (PE)
8163264       0x7C8FC0        Microsoft executable, portable (PE)
8168128       0x7CA2C0        Microsoft executable, portable (PE)
8179104       0x7CCDA0        Microsoft executable, portable (PE)
8183232       0x7CDDC0        Microsoft executable, portable (PE)
8186688       0x7CEB40        Microsoft executable, portable (PE)
8201888       0x7D26A0        Microsoft executable, portable (PE)
8202944       0x7D2AC0        Microsoft executable, portable (PE)
8262048       0x7E11A0        Microsoft executable, portable (PE)
8280992       0x7E5BA0        Microsoft executable, portable (PE)
8282688       0x7E6240        Microsoft executable, portable (PE)
8283680       0x7E6620        Microsoft executable, portable (PE)
8290240       0x7E7FC0        Microsoft executable, portable (PE)
8302016       0x7EADC0        Microsoft executable, portable (PE)
8307520       0x7EC340        Microsoft executable, portable (PE)
8308064       0x7EC560        SHA256 hash constants, little endian
8311223       0x7ED1B7        mcrypt 2.2 encrypted data, algorithm: blowfish-448, mode: CBC, keymode: 8bit
8326976       0x7F0F40        Microsoft executable, portable (PE)
8375712       0x7FCDA0        Microsoft executable, portable (PE)
8383984       0x7FEDF0        Microsoft executable, portable (PE)

What I did not know was whether the BIOS image contains the default settings of the NVRAM and if it will work when flashed to the chip.

Before trying to desolder anything, I first disconnected a lead of the battery and insulated it.

DSC_0396

I desoldered the flash by applying lots of solder to the pins and repeatedly heating both sides with a soldering iron until the chip became loose. Then I picked it up with tweezers. If you also want to do this, pay attention to the passives around the chip. They can be damaged very easily.

DSC_0401DSC_0403

To flash a new BIOS, I needed an SPI programmer and I did not want to wait a month for getting one from China (a thing like this would be best suited).

I started searching for an alternative for buying an programmer and even tried using an ESP8266 module as flash programmer. The problem was that the ESP needs a 3.3V supply and I needed a level shifter, which I also did not have for 1.8V. So I built one with NPN transistors.

DSC_0562 DSC_0561

But this did not work out either. Most likely there were signal integrity issues with the long wires to the flash chip. I tried reading the flash chip with esptool but only got unknown error messages.

So after this did not work I tried the same thing with an Arduino flashed with frser-duino, which (suprise) did not work 🙂

Frustrated and prepared to take the risk of a dead flashchip, I used my 3.3V only CH341A programmer and it worked! The flash survived although the voltage was out of spec and even above the maximum ratings.

I used a fork of flashrom for the CH341A programmer that can be found at GitHub.

DSC_0406

After flashing I resoldered the chip and reassembled the tablet.DSC_0394

And it worked just fine. It booted with a message that the default NVRAM values are being initialized.

DSC_0573

 

So what I learned from this was that BIOS updates work by backing up the NVRAM section of the flash to RAM, completely erasing and programming the flash and afterwards restoring the NVRAM to the chip, which is quiet neat in case of damaged settings. But I really hope that in future Tablet manufacturers will include some sort of reset points for the BIOS settings, especially if there are severe bugs which lead to a hard-brick by simply changing a setting.

Also you can sometimes get away with exceeding the specification of an IC for a very short time if you do not need the certainty that it will not blow up.

Online AVR simulator

Recently the micro-controller course at my university started. We learn programming assembler for the ATMega 1280 and use a commercial development-board. Because I wanted to work from home, I came up with an idea.

What if we compile an AVR simulator with Emscripten so everybody can easily access it from the web?

Emscripten is a C to JavaScript compiler that can be used to turn PC applications into Web applications.

Turns out that this was quiet doable and so simavr.js was born.

simavr.js can be found here: http://wq.lc/avr

It provides access to all IO ports of the AVR with simulated LEDs and buttons and should support most of the features of the chip.

Currently only .hex file loading is implemented for the flash memory. The EEPROM is simulated internally and can be used but data preloading support is missing.

In the near future there will be support for emulating other peripherals such as text LCDs and the UART. I’m also planning to implement an online logic-analyzer which can be used to inspect signals without having to actually build a board and probe it. Support for multiple MCU models will also be added soon.

My source code is on Github.

https://github.com/donothingloop/simavr_emscripten
https://github.com/donothingloop/simavr.js

I have provided some test files. These were generated by compiling some small c programs.

This example uses the timer1 to blink all avaliable LEDs:

#include <avr/interrupt.h>
#include <avr/io.h>

int main(void) {
 volatile uint8_t *ddr = &DDRA;
 int i;

 for(i = 0; i < 10; i++) {
 *(ddr) = 0xFF;
 ddr += 0x03;
 }

 TCCR1A |= (1<<WGM11);
 TCNT1 = 0;
 TIMSK1 |= (1<<TOIE1);
 sei();
 OCR1AH = 0x04;
 OCR1AL = 0xE2;
 TCCR1B |= (1<<CS12) | (1<<CS10);

 for(;;) {}
}

ISR(TIMER1_OVF_vect) {
 volatile uint8_t *port = &PORTA;
 int i;
 for(i = 0; i < 10; i++) {
 *(port) = ~(*port);
 port += 0x03;
 }
}

Save this to blink.c

To compile it first install the required tools to cross-compile the code. On Ubuntu you can enter the following command to install them:

sudo apt-get install avr-libc gcc-avr binutils-avr

After the installation is completed, the code can be compiled:
avr-gcc -mmcu=atmega1280 blink.c -o blink.elf -O3

Now the resulting elf file has to be converted to an hex file:

avr-objcopy -j .text -j .data -O ihex blink.elf blink.hex

Open http://wq.lc/avr/ (link opens in new tab) and click on “Open .hex file”. Select the blink.hex from your PC.

The firmware should now be running and you should see the LEDs of PORTA to PORTG blinking.

 

If you are somehow unable to compile this or just want to test the simulator, a compiled copy is available at http://wq.lc/avr/blink.hex

APRS on Linux – Direwolf and Xastir

I recently built a usb soundcard with push-to-talk functionality, which is perfect for interfacing the Baofeng UV-5R to the PC and sending APRS over it. It is quite simple to set-up and works well.

First clone my fork of direwolf with support of the CM108 soundcard:

git clone https://github.com/donothingloop/direwolf_cm108.git
cd direwolf_cm108
make

Open the direwolf.conf file and set the following options:

MYCALL <YOUR CALLSIGN>
AGWPORT 8000
KISSPORT 8001
PTT CM108

Then install xastir.
For Ubuntu, Raspbian, Debian enter:

apt-get update
apt-get install xastir

After the installation has completed, start xastir. You should get a window looking like this:

xastir
xastir (no, i’m not in Africa)

Click on Interface and then on Interface Control.
In the following dialog click Add.
Select Networked AGWPE and click on Add.

xastir1

Check if the port is 8000 and change your Digipeater paths according to your country’s requirements. Then click on OK.

You can now try to transmit. Set your radio to your local APRS frequency, click on Interface and then on Transmit Now!.
The red led of your soundcard should turn on and your radio should start transmitting.

New design of my PTT Soundcard

I already mentioned in another post that I hacked together a CM108 based sound card with a PTT output. Unfortunately there are no pictures of the build-process which involved a lot of hot-glue. But as it worked really well and some friends already wanted to have one I decided to build a more professional version of it. It is based on the reference design of the CM108. The USB connector is a micro-USB one, which has the advantage that everyone has already got the required cables for their smartphones.

Top view of the soundcard
schematic
board

Continue reading New design of my PTT Soundcard

Tetra EchoLink repeater now online

Recently, I got my amateur radio license with the call sign OE1VQS and spent quiet some time at the “A1 Amateurfunk Club”. They have set-up a repeater for the digital mode called TETRA, which isn’t that widespread in the ham community in Austria. They thought about implementing EchoLink support on the repeater for quite some time. But after someone brought a Raspberry PI Model B+ to the club, we’ve decided to use it with svxlink as EchoLink gateway and let people which do not own a TETRA compatible radio join the conversation.

b2b_product_mth800_lg_gb-en

There was already a Motorola MTH800 which we could use.

Continue reading Tetra EchoLink repeater now online