3G Dongles suck. Or maybe Linux support for 3G dongles sucks. Either way, if you're hoping to accelerate your hair loss, I can recommend attempting to setup a 3G dongle with a Linux based device.
This brief guide will cover setting up the ZTE MF190 modem with a Mikrotik router.
29/08/2017
18/08/2017
Flashing a bootloader on to an STM32 'Blue Pill' using a Raspberry Pi
I am currently preparing some STM32 'Blue Pill' Microcontrollers for use with an Amateur Radio project. From the factory these appear to arrive without USB support, so before we can flash any firmware over USB you must first flash a new bootloader over the UART interface.
I used a USB to Serial adapter set to 3.3v, but you could use the Raspberry Pi's UART if you wish. Remember, if you're using the Raspberry Pi 3 you will need to disable the built in bluetooth and TTY running on the UART first.
I used a USB to Serial adapter set to 3.3v, but you could use the Raspberry Pi's UART if you wish. Remember, if you're using the Raspberry Pi 3 you will need to disable the built in bluetooth and TTY running on the UART first.
13/08/2017
Hidden London: Highgate wilderness walkabout
It's no secret that I'm a big fan of the London Underground. To be clear, I don't consider myself a true anorak as I can't tell you the exact diameter of the wheels on an S Stock Car or the top speed of a fully laden A stock train, but I have an appreciation of the infrastructure and history of the Underground.
Having attended Hidden London tours of Aldwych, Euston and riding the Metropolitan No. 1 steam locomotive between Watford and Chesham, I grabbed some tickets for the newly announced 'Hidden London: Highgate wilderness walkabout' tour as soon as they were released.
My wife and I attended the tour today and both left a little disappointed, primarily due to the cost of the event - £31.50 each. Perhaps we had misguided expectations, however in comparison to Euston and Aldwych (£36.50) and the steam train (£20.00) which were all all fantastic experiences, the pricing seems a little ambitious.
Having attended Hidden London tours of Aldwych, Euston and riding the Metropolitan No. 1 steam locomotive between Watford and Chesham, I grabbed some tickets for the newly announced 'Hidden London: Highgate wilderness walkabout' tour as soon as they were released.
My wife and I attended the tour today and both left a little disappointed, primarily due to the cost of the event - £31.50 each. Perhaps we had misguided expectations, however in comparison to Euston and Aldwych (£36.50) and the steam train (£20.00) which were all all fantastic experiences, the pricing seems a little ambitious.
If you plan on going on the tour and don't want any spoilers, stop reading here! However if you're not planning on going or are now having second thoughts and want to know a little more about our experience, read on.
Discovering and updating a guests hostname from the GNS3 API.
In a previous post, I reinvented the wheel whilst trying to discover the hostname of the GNS3 API from within a guest. Once I'd wasted an evening reinventing DNS, it was time to move onto the main objective - allowing a guest to discover its GNS3 hostname from the API and update the relevant entries in /etc/hostname and /etc/hosts, so next time the puppet agent ran it would pull the appropriate configuration.
I've chosen to use Python as it's the language I'm most confident with. You can view the GNS3 API documentation here
I've chosen to use Python as it's the language I'm most confident with. You can view the GNS3 API documentation here
This script was created for Debian and Ubuntu based hosts but will probably work for other distros with minimal tweaking. If you want to skip the blog post and view the code, it's on github
04/08/2017
Requesting custom DHCP options with dhclient, or in my case, reinventing the wheel!
Occasionally I do stuff that's not amateur radio related. Today was one of those days.
I'm currently preparing a virtualised 'lab' to experiment with VoIP (Voice over IP), networking, and potentially some DMR network (radio) stuff in the future. I will be using GNS3, a program that was created to emulate networking devices but now also does a great job of emulating servers and their associated network topology.
Historically when using GNS3 I've configured each 'node' manually, however its 2017, dev-ops is hot, and manual configuration is not. Enter puppet, a configuration management tool that treats configuration more like code. You create a 'manifest' that contains instructions and templates on how to configure a device, and then an agent will then pull the configuration from the puppet master and apply the changes. Simple.
As far as I can tell (It's early days), puppet relies heavily on using hostnames to figure out which device needs which configuration. However, virtualised nodes within GNS3 are usually built from a template, and will share the same hostname when first configured. Additionally when a node is created, I don't know its MAC address, UUID, or any other identifier until its created. GNS3 will allow you to configure a hostname 'label' however this isn't communicated with the node out the box.
So, the plan? Create a script that will run on each node, query the GNS3 API and discover its own hostname, update it, and then puppet can do its thing and pull the correct configuration. BUT. How will the node know the IP that the API is running on?
I figured I could use DHCP options to send the IP of the API to the node, so it could then query the GNS3 API and grab it's hostname. I did the research and leg work, and then had an epiphany - what if someone had already invented a service that allows a device to find the IP address of a service... like... the Domain... Name... System. DNS.... Already invented.
For the sake of posterity, I've written up my findings below.
I'm currently preparing a virtualised 'lab' to experiment with VoIP (Voice over IP), networking, and potentially some DMR network (radio) stuff in the future. I will be using GNS3, a program that was created to emulate networking devices but now also does a great job of emulating servers and their associated network topology.
Historically when using GNS3 I've configured each 'node' manually, however its 2017, dev-ops is hot, and manual configuration is not. Enter puppet, a configuration management tool that treats configuration more like code. You create a 'manifest' that contains instructions and templates on how to configure a device, and then an agent will then pull the configuration from the puppet master and apply the changes. Simple.
As far as I can tell (It's early days), puppet relies heavily on using hostnames to figure out which device needs which configuration. However, virtualised nodes within GNS3 are usually built from a template, and will share the same hostname when first configured. Additionally when a node is created, I don't know its MAC address, UUID, or any other identifier until its created. GNS3 will allow you to configure a hostname 'label' however this isn't communicated with the node out the box.
So, the plan? Create a script that will run on each node, query the GNS3 API and discover its own hostname, update it, and then puppet can do its thing and pull the correct configuration. BUT. How will the node know the IP that the API is running on?
I figured I could use DHCP options to send the IP of the API to the node, so it could then query the GNS3 API and grab it's hostname. I did the research and leg work, and then had an epiphany - what if someone had already invented a service that allows a device to find the IP address of a service... like... the Domain... Name... System. DNS.... Already invented.
For the sake of posterity, I've written up my findings below.
01/08/2017
Flashing MMDVM on an STM32 Nucleo using OS X
The MMDVM Modem is made up of several components-
- The interface board - Interfaces with the radios and performs the necessary filtering and amplification of the Tx and Rx Signals
- The Modem - an embedded microcontroller for doing the analog to digital and digital to analog conversion and sampling.
- The Host - usually a Raspberry Pi. Manages the modem and performs actions such as relaying DMR frames to the network.
The MMDVM software will run on several different platforms including the Arduino Due, the Teensy's, and the STM32 Nucleo. The DUE's are EoL, and the Teensy's are expensive, which left the STM32 as the logical option.
This guide is aimed at flashing the STM32 Nucleo board (STM32F446RE) for use with one of F0DEI's highly recommended MMDVM boards using MAC OS X. If you're using another MMDVM board, you may need to tweak the Config.h file accordingly.
I've not used an STM32 Nucleo before, so I had to do some research to figure out how to flash it. I've written up my findings below.
If you're using Windows I recommend F5UII's blog post here
The STM32 Nucleo |
F0DEI's MMDVM Board |
I tested this on 03/05/2020 and it worked as expected!
Subscribe to:
Posts (Atom)