TM-D700 Portable Ham Radio Rig

Since the first blog post announcing the start of my adventure into the world of ham radio a couple of months have passed in which I have tried to come up with a creative solution to my main problem: I do have two QTH's and whilst the reception is great at my secondary location (OE3) reception is miserable at my primary location (OE5). Since I spend most of my time in OE5 the only solution is to go mobile.

Now this is were my other problem arises: I do only have one radio which I am carrying from QTH OE5 to the car, from the car to QTH OE5, from QTH OE5 to car to QTH OE3, ... The front panel of my Kenwood TM-D700 is not connected with the transceiver which means I have to carry a lot of sensitive equipment around everytime I move the radio. Since I am also starting to look into SOTA participation I have realised the need for a rugged setup for easily carrying around my radio. Let's begin ...

The basic chassis for the portable ham radio rig consists of CNC milled aluminium plates connected via 3D printed connectors:

The transceiver part of the Kenwood TM-D700 is mounted in the middle of the chassis:

In front a 10 mm macrolon plate is mounted to serve as a base plate for the display which is glued to the macrolon plate.

On the bottom of the chassis rubber feet are applied to prevent scratches when keeping the radio rig on smooth surfaces such as your dining room table 🙂

On the next picture you can actually see the portable ham radio rig happily sitting on the dining table:

On this picture you can clearly see that the display mount is glued to the macrolon plate. No external glue was applied since the display mount is delivered with an extremely adhesive base.

A handle was added on top to have an easy way of picking the radio up and move it somewhere else:

Side view of the complete portable ham radio rig with handle

It works terrific 🙂 Setting up ham radio in my car takes now less than half of the time previously needed. I could only further reduce that time by buying a second radio but I'd rather not amass too much different radios this early on my ham radio journey 🙂

0

std::numeric_limits::min() vs. std::numeric_limits::lowest()

While this is quite a technical blog post it took me a little while to fully understand the implications on my code and I therefore would like to share this insight with my readers. This article applies to everyone who likes to use software constructs like the following one:

Looks reasonable, doesn't it? However, the tricky bit is that min() does return the minimum representable finite POSITVE value of the type provided as template argument (in this case float). If x and some_other_value are always positive, this is not a problem. If some_other_value can also be negative, above statement will not work as intented.

What is the correct solution? Use std::numeric_limtis<T>::lowest() (Only available from C++11 on!). If I print the concrete values of min(), max() and lowest() on my dev system I do get the following results:

The correct code sequence should therefore be:

This stumbling block is especially heinous because the following software construct works as desired in every case:

0

Erase the complete flash memory on a STM32 with OpenOCD

Lately I had the pleasure of working with Frank Voorburg on integrating his OpenBLT bootloader in a STM32F4 (precisely a STM32F405RG) based project. As a means to debug the microcontroller OpenOCD in combination with an Olimex ARM-USB-TINY-H JTAG adapter was used. For those not familiar with openocd, you can simply install it via

OpenOCD can be started via

However, it is necessary to have a openocd.cfg file present in the directory where openocd is invoked which defines the used microcontroller as well the used JTAG adapter. In our case openocd.cfg looked like that:

At one point of our integration effort it was necessary to erase the complete flash memory of the target microcontroller. Since the information on how to do it was not so easy to find I decided to document it here. First thing to do is to establish a telnet connection to the OpenOCD driver:

Than the execution of commands within the microcontroller needs to be stopped:

With the next command one can obtain various information about the flash present at the microcontroller:

The important thing here is that the STM32F4x uses the same flash model as the STM32F2x. This is important because the flash type 'stm32f2x' is used as a part of the next command to completely erase the flash:

Done 🙂 You have completely erased the flash of your STM32F4x microcontroller 🙂

0

Featherweight Schnauzer Part 20

Since the work on all the mechanical components of Schnauzer is complete the focus now shifts on the completion of the electrical parts. Since the ESCs and the power wiring is already installed the next step is the integration of the batteries into the system. Two 2-cell LiPo batteries with a capacity of 1800 mAh each are used. Those two batteries are connected in serial providing one 4-cell LiPo battery for the ESCs.

Because of the tight space situation in the robot the battery cables need to be shortened down a bit. This is done by cutting off the power cables and soldering a new EC3 female power plug to the cable. Attention: If you ever work with LiPo batteries make sure that the bared red cable touches the black cable at no point during your soldering process - otherwise sparks (in the best case) and an explosion (in the worst case) will ensue. At least one of the two cables needs to be fully insulated.

The next step was to manufacture an adapter which allows to create a single 4-cell battery from two 2-cell batteries. Such an adapter can be seen in the picture below and consists of two EC3 male power plugs. Those plugs are connected with the two batteries while the other end of the cable if connected to Schnauzer's power distribution system.

Since the frame of the robot is made out of Hardox (which makes it really tough to drill holes into it) I had to think of a new method to mount the batteries to the frame. Luckily I do have some spare strong neodymium magnets lying around from the beetleweight arena build.

Two of those neodymium magnets are placed on a rectangular piece of foam material (to provide some sort of cushioning from hard hits against the robots frame). Good old duct tape is used to mount everything together.

The next pictures shows the assembled battery completely covered in duct tape.

In the next picture you can see the two batteries mounted at the rear end of Schnauzer. Since each magnet has a holding forvce of ~ 110 N the batteries are held firmly against the Hardox frame. I am confident that they shall not come loose during a robot battle.

Last but not least a close up shot from the adapter which creates a single 4-cell battery out of the two 2-cell batteries. Also to be seen: The 80 A fuse 😉

Schnauzer is now ready to go 😉 Well nearly, I am still working on a last electronic component which should provide Schnauzer with an edge in the arena ... more details after the event 😉 Speaking of an event: The German Roboteers Assocation is holding a full contact featherweight competition on April 8th, 2017. More details here.

0
Seite 1 von 46 12345...»