Posts by Roger Clark:
Announcing www.opengd77.com a forum for OpenGD77 usersRead the rest of this entry “
Unlike the “Jumbospot” most duplex MMDVM hotspots are not sold in a case. You simply get the “modem” board and normally need to buy a Raspberry Pi and case separately.
I’ve tried making my own case from laser cut perspex, but it ended up being quite bulky, and I prefer to put RF devices into metal boxes, so I started to look for a suitable case which could be modified and eventually found this one.
As links to online vendors go dead very quickly, I’m not going to post any links, but if you search for Aluminium case Raspberry Pi 3 you should find cases which look like this .
My initial concern with using a metal case, was that the WiFi would not work very well, but somehow the 2.4GHz WiFi signals must be able to leak out of the case, because I found that the WiFi connectivity was not a problem at all, and it even worked where I thought my WiFi router signals were quite weak.
There are 2 main problems with fitting the hotspot into the case…
- The antennas
With this box, I was able to drill holes in the top which were just big enough to insert antennas that normally come with the hotspot board.
- Securing Raspberry Pi to the case and still being able to secure the hotspot board to the raspberry pi.
With this box. The Raspberry Pi board is only secured by one screw, which attached to the post in the lower right corner of this photo.
Additionally the end of the RPi which has the USB sockets rests on a shelf which is part of the end cap, and the USB sockets are a reasonably tight fit, which overall seems to retain the RPi board well enough.
What the case does not have however, is any way to access the bolts that I use to secure the hotspot board to the RPi.
There are several different ways to secure the hotspot to the RPi, and I normally use 2.5mm bolts (about 30mm long), with plastic or metal tubes between the hotspot and the RPi on the side of the hotspot furtherest from the connector.
The other way to do this is to use threaded pillars, and small screws, however I couldn’t find any suitable pillars which didn’t bump into the USB power socket on the RPi, but I had some thin metal tubing.
So my solution was to drill 3 access holes in the base of the box, though which I could insert the hotspot securing bolts, after the RPi had been bolted in place.
Note. Its not possible to access the securing screw if you try to pre-assemble the RPI and hotspot together, because the hotspot gets in the way.
I guess it could be possible to cut the corner off the hotspot board, to allow access to the securing screw, but I don’t mind having some holes in the base of the case, as it helps a bit with ventilation 😉
Here is the case, with the RPI fitted and secured by the single screw, which can be seen in the upper left corner of the board in this photo.
I’ve also fitted heat sinks to my RPi 3B because my shack often gets to 30+ degrees C in the summer, and a little extra cooling does no harm.
With the RPi in place, the 3 bolts that secure the hotspot can be inserted though the access holes in the base of the case
And then fed through the metal tubes, before being secured by a nut
(In this photo I removed one end of the case so that the tube could be seen)
To stop the nuts working loose, I put some clear nail varnish on them, because its quick drying, and cheaper and easier to get hold of than threadlock.
You’ll have noticed that my hotspot seems to have 3 extra wires which go down though into the RPi.
These are the wires which I use to control the hotspot using a 2 position switch, and connect to a RPi GPIO pin which is accessible on the hotspot board.
At the moment, I don’t have a small switch which is suitable for this case, but I didn’t want to unsolder the wires, so I’ve simply pushed them out the way to stop them shorting onto anything.
And this is what the final case looks like.
Note. I’m using right angle adaptors on the antennas. This is for several reasons…
I think that having both the Tx and Rx antennas in the same polarisation , in very close proximity to each other is not a good design idea, and I always use right angle adaptors so that I can orient the antennas away from each other.
And… I find its handy to be able to stand the case on its end, and have the antennas as “bunnies ears”,
And.. I can almost completely fold the antennas away, but unscrewing then a bit and rotating them to be along the length of the case.
Unfortunately the antennas are slightly longer than the case, but only by a few millimetres.
My next upgrade will be to refit the switch, as I think I will be able to remove the end cap at the SD card end of the RPi and fit a small toggle switch, which I can then use to easily switch between either it being a Simplex or Duplex hotspot, or use it as a network switch between BM and DMR MARC, or possibly use it as a frequency switch for instances where I’m in proximity with another hotspot on the same frequency.
I’m also hoping to make a display that I will fit to this case, but that’s a far bigger project
I wanted to connect a hardware debugger into another of my Radioddity GD-77s, but didn’t want to drill a hole in the side like I did on one of the radios…
But I then realised that the rubber protector that goes over the 2 jack sockets in the side of the radio, can be removed, and this gives a handy hole, through which I can feed the Serial Wire Debug wires.
Inside the radio, the wires are soldered on 4 pads on the back of the main PCB, roughly in the area between the # and 0 buttons on the keypad.
To prevent the wires either breaking off where they are soldered or worse, pulling the pads off the PCB (which is a common problem), I have used hot glue to secure the wires close to where they are soldered to the PCB
Taking the GD-77 this far apart is relatively easy, as its actually only held together by 2 screws near the base of the radio, and also by the 2 ring nut’s around the SMA connector and the volume / on/ off knob.
The 2 obvious solder pads just in from the 2.5mm jack socket are the speaker connections, which I have temporarily unsoldered as the wires to the speaker are very short.
The white and black connector on the left in the photo is for the flexible ribbon cable for the display / keypad PCB which screwed to the front of the radio.
To detach the ribbon cable, you have to separate the black part of the connector from the white part, using a small flat blade screwdriver.
The trickiest thing when re-assembling the radio is re-inserting the ribbon cable and then pushing the black part of the connector across so that it crimps the ribbon in place.
But I’m becoming a dab hand at doing this as I’ve repaired server GD-77’s for members of the local radio club, where they received GD-77s where the ribbon cable was not securely clipped or the cable was not pushed in far enough, so that over time the display became partially disconnected.
Some eagle eyed readers will notice that I pealed off the Radioddity logo, because I wanted to see if anything was underneath. As you can see, nothing is…
It may however be fun to make another label to replace the Radioddity one, but I’m not sure yet, the best way to do this.
Another small note…
To erase the CPU, it needs to be halted by the debugger, which requires the Reset pin to be connected. In my case that’s the purple wire.
However once the CPU has been erased once, the Reset is no longer required, so I could in theory open the GD-77 again and remove that wire.
But Its not causing too much hassle at the moment, so I simply leave it disconnected, or connect it via a resistor to +3.3V from the debugger, to prevent RF pickup on the reset pin which can cause the radio to reboot if you transmit with 5W, or sometimes even with 1W!
Well, that was my thought 2 days ago, when I was informed by Kai, DG4KLU that a open source reverse engineering tool, developed by the NSA had just been released to the public.
For more details visit https://ghidra-sre.org/
This is great news in relation with reverse engineering the GD-77 firmware, because Ghidra has a lot of the features, previously only available in very expensive programs like IDA Pro.
Armed with Ghidra, I have started to explore the internals of the firmware.
There are multiple ways to attempt to understand what each function does in the firmware, but one way is to work backwards from the hardware registers in the MK22 MCU, which do things like send data to the AT1846 RF transceiver chip, and to the external SPI Flash memory, the external EEPROM and also the keypad and the screen.
The memory addresses of these registers is documented in the reference document for the MK22, but since there are over 1300 registers, manually correlating each memory address in found in the firmware back to its name and function in the reference, would take forever.
Luckily I found out that its possible to create a Processor Specification (PSPEC) file for any microprocessor and use it when the firmware binary is imported into Ghidra
However, getting data on all 1300 registers, from the PDF reference document into the XML PSPEC file required a number of stages of manual and automatic processing, which I won’t bore you all with at the moment.
But eventually, I was able to use my newly minted PSPEC file to annotate all the disassembled and decompiled firmware code.
For example here, is some code which interacts with the SPI interface (though at the moment I don’t know which SPI device or what its sending or receiving)
Ghidra is also capable of decompiling to C code, and even though this could could not be recompiled back into a working version of the firmware, its a great way to get a better idea of what each function does
(this is not the same function as show in the disassembly view in the image above)
And there are also graphic features available to show the hierarchy of functions
And also Function Graphs
Not to get anyone’s hopes up, because there is still a big mountain to climb, in terms of understanding the internal workings of the firmware, so that it can be enhanced or bug fixed, but it does look like things will be a bit easier by using Ghidra
As requested by various people. Here is my PSPEC file for the MK22 processor.
Note I just added the hardware registers. I have not had time to add processor specific ISR vectors, but they would be easy to add
Also. I’ve taken some more memory snapshots, including these 2, one during transmission and one when receiving a signal from VK4NBL
So here are those files
My DMR ID is 5053238 (and my callsign is VK3KYY)
I’m pretty sure VK4NBL’s id is 5054068
Note. To import the memory snapshots, you have to press ALT+I which then appends / merges the file to the existing memory map
Don’t forget to use offset 0x1fff0000 when importing the RAM snapshot
In firmware 3.1.8
Using the memory dumps I have found a few interesting memory addresses
I’m now sure that the current channel data structure is located at 0x1fff3a04, or possibly a bit lower in the memory
0x1fff3a04 upper byte seems to be a flag, as its set to 0x05 when I’m on channel and 0x90 when I’m on a VFO
The next remaining 3 bytes are the Tx TG.
And the Rx Group list starts at 0x1fff3a08
If I change 0x1fff3a04 then press PTT it transmits on the TG I specified.
It looks like the function at address 0x27b52 is called constantly, and if the memory location pointed to by register r1 is contains 0x0F, it seems to indicate that a signal has been received.
So if you put a break point on 0x27b5a the code only halts when there is a new signal received.
Looking at what references the function at 0x27b52, I found this
PTR_LAB_00027b8c+1_00027f50 XREF: FUN_00027b90:00027cd0(R)
00027f50 8d 7b 02 00 addr LAB_00027b8c+1
00027f54 91 7b 02 00 addr FUN_00027b90+1
00027f58 53 7b 02 00 addr FUN_00027b52_event_loop+1
(I labelled the function at 0x27f58 with the extra text “_event_loop” , to make it easier to find, but I should have probably called it “_task”, as it looks like these 2 functions are possibly the top level task list which is bring run by the RTOS.)
Jason VK7ZJA has kindly sent me a list of what all the pins on the MK22 MCU seem to be connected to.
You can download the text file from here MK22 connections GD-77
Hopefully this will help getting to grips with the firmware
I’ve been experimenting with various ways to display information on my PiStar based hotspot, including the small OLED displays.
I found the the OLED is to far to small, so I splashed out and bought what I thought was an official Nextion 2.4 inch display, from a eBay vendor.
I was aware that there are clones of the Nextion, which don’t work with the official Nextion editor and don’t accept data files produced by the official Nextion editor.
But I specifically ordered a board which looked like a Nextion made by Itead and had a Nextion part number (beginning with NX)
The photo on the product I ordered looked like this.
When the display arrived, I noticed that the PCB did not match the photo in the eBay listing, but it did have the correct model number and also had what looked like the Nextion logo.
Clearly the board is completely different, despite seeming to have identical model numbers.
I became suspicious about whether this board was an authentic Nextion, when I was unable to upload the “TFT” configuration files via SD card.
The upload always stopped whilst displaying “SD Card Update…..” rather than going on to copy the graphics and configuration data from the SD card.
Assuming there was something wrong with the “TFT” file I got from the web, tried connecting the display via a USB to serial converter to my PC, and I managed to use the official Nextion editor to upload a set of screens I downloaded from the MMDVM github account (G4KLX)
The display then seemed to work OK with PiStar, but I thought I’d try a different screen layout, and this is when the problems started …
When I tried to upload the new layout using the Nextion editor and the USB to serial adaptor, I found that the Nextion editor would no longer connect to the display.
However, when I reconnected it to Pi Star, I found it was still working.
Not to be deterred, I thought I’d try to upload via SD card again, and after trying various micro SD cards, I eventually found an old 4Gb card, which was probably 4 years old, which was recognised by the display, and I was able to upload a different layout.
After removing the SD card and removing and reconnecting the 5v input to the Nextion, the new layout worked OK, but unfortunately this was the last time I was able to use the display.
Because I thought I’d try another different screen layout, and after uploading that layout using the micro SD card, when I removed the SD card and removed and reconnected the 5v input to the “Nextion”, I found it was no longer receiving any data from PiStar.
Just in case something had happened to my hotspot board, I connected the USB serial adaptor to the Nextion output on the hotspot and used a terminal program on the PC to confirm that the hotspot was still sending serial data to the display.
Currently I have no idea whether this board was an official Nextion or not. I didn’t buy it direct from ITead (my mistake), and instead bought it from an eBay vendor in China, via eBay, because the vendor offered free shipping.
The vendor claims it is an authentic Nextion, but offered $4 compensation, which I rejected because I’d rather give negative feedback on eBay and warn other potential buyers that these boards may not be genuine.
My advice to anyone who is thinking about attaching a Nextion to their PiStar hotspot, is to buy direct from ITead, even though its likely to cost $10 more (about 30% more) than from third party vendors, because you are guaranteed to get a genuine board, and are also likely to get support from ITead if you end up having the sorts of problems I’ve had.
Even if my board was not genuine, I still don’t understand why it failed.
What appears to have happened is that initially the serial Tx line probably stopped working, hence the Nextion editor would not connect to the display, but the display still seemed to work when I connected it to my hotspot, since PiStar only sends data to the display and does not expect a response from the display
Subsequently, I think the Rx line into the display probably also failed.
I’ve used STM32 microcontrollers a lot, and I’ve never had a problem before with the serial Tx and Rx lines, even if I connect them the wrong way around. So I find it surprising that the serial lines on this STM32F030 have failed one after the other.
I did not disconnect the serial Tx and Rx lines from the hotspot, when I removed and reconnected the 5v input wire, to the display, when I was uploading via micro SD card, but again I have never had a problem with other STM32’s with leaving input signals connected when the MCU is not being powered.
However perhaps the STM32F030 used on these nextion’s is not very robust, and leaving the serial wires connected when I power cycled the display was enough to damage them.
Now that I’m left with a “bricked” display, I’m going to try to connect to the 5 pads on the back of the PCB, which I presume are the SWD debugger / programmer connections, but I’m going to need to work out which pads are which connections, because the Nextion is not open source and there is no documentation about what these pads are connected to.
Hopefully I’ll be able to use the screen for something, but for the moment its going into my junk box 😉