Just a quick post on a hardware hack that’s possible, but quite difficult, on the GD-77 to increase the internal memory from 1M bytes to 8M bytes

The GD-77 memory consists of these 2 chips

(Photo curacy of Jason VK7ZJA’s website, since I forgot to take a “before photo”)

The chip on the left is a Winbond 25Q80, 1M byte (aka 8M bit) SPI flash memory

The chip on the right is Atmel 24C512 (or possibly a equivalent device) which is a 64k byte EEPROM.

The EEPROM is used to store half of the codeplug (things like the basic settings and the Zones)

The 1M byte Flash chip is used to store the top half of the codeplug, and the calibration data, as well as one of the display fonts, and also the DMR ID

The 1M byte Flash chip is almost 100% utilised and there is no room left to store, either more codeplug data or more DMR ID data.

The main limitation is the DMR ID data, because even in the version of the official firmware which I modified, I could only store around 15,000 callsigns + names, whereas the entire DMR ID database is now around 130,000 callsigns.

Looking at what other flash memory chips were available, I found that Winbond make devices with more memory, which are software compatible with the 25Q80, but unfortunately are not in exactly the same physical package.

However it is possible to bend the legs under the larger package and solder the 25Q64 in place of the 25Q80, and upgrade the radio to 8M bytes (aka 64M bits) of main memory.

Or course, just increasing the memory size does not make any difference unless the firmware is also changed, so that the addition 7Mb of memory is used.

So I modified the official firmware, so that the DMR ID data was stored. Rather than address 0x30000 (hexidecimal) I changed it to 0x100000 (i.e the 1Mb point).

I also changed the DMR ID maximum size from 128k to 7M bytes.

The next thing to change was the DMR ID section in the Community CPS, to upload the data to the new location, and to remove the data size limit.

With these changes in place to the hardware, the firmware and the CPS, I was able to download the DMR ID for multiple regions, and in the end I found that the data from ham-digital.org, (which I use for the DMR ID system in the community CPS), seemed to only show around 60,000 active callsigns on DMR in the last 12 months.

So I uploaded that data to the GD-77; rebooted it and used my hotspot connected to Brandmeister to listen to various TG’s around the world, to test whether the DMR ID system was indeed storing 60,000 callsigns…..

Which it was.

So far so good except for two problems.

1. The official CPS upload speed is very slow, both for the codeplug and also for the DMR ID, because it uses the same system to transfer the data.

   The speed to upload data appears to approximately 10,000 IDs per minute.

   Hence it too between 6 and 7 minutes to upload the 60,000 IDs, and for the full 130,000 DMR ID’s which I could download from RadioID.net, it would take approximately a quarter of an hour to upload to the radio.

2. The data that the Community CPS uses, is downloaded from ham-digital.org, because I use the filtering available on their servers, to select which region’s ID’s to download. For example all ID’s starting with 505 for Australia.

   I’ve found that its not practical to download the entire DMR ID data for all regions from ham-digital, because it seems to take too long, and the download times out.
   And.. even when I managed to download data on all regions, from ham-digital, by downloading each region separately e.g. all ID’s starting with 1, then all ID’s starting with 2 , etc.  I found the total was only 60,000 rather than the expected total of at least 120,000

   So to make use of the additional memory, I would also have to change the CPS to download from RadioID.net, including changing the CPS to read the different format in which the RadioID.net data is delivered.

Unfortunately, I don’t think I am going to be able to modify the official firmware so that it uploads any faster, because this is intrinsic in the way the firmware operates, using a Real Time Operating System to handle the USB, which it does in thousands of small 32 byte transfers.

So currently, I think this modification would only be useful some time in the future, using Kai’s firmware.

And with Kai’s firmware, the extra memory may not be absolutely necessary, since the codeplug size is likely to be much smaller, since it does not need multiple duplicate channels, and won’t store the font etc in the Flash memory.

This would probably allow around 700k to be allocated to DMR ID storage, which could allow for around 60,000 ID.

Also, if more radio’s start being able to transmit DMR “Talker Alias”, the DMR ID system may eventually be redundant, because “Talker Alias” allows 31 characters of additional data to be sent with the transmission, and this would be plenty to store the callsign, name and some other information e.g. location locator.

So although this was an interesting technical exercise it appears to be a a bit of a dead end at the moment

Another quick post, mainly to get some feedback.

Now that the open source GD-77 being written by Kai, DG4KLU, is progressing and can receive on both FM and DMR. One of the other things on my, rather large, To Do list is to write a CPS to support Kai’s firmware.

Currently I’ve added some functions, so that the official codeplug, which is already in the GD-77’s memory, can be partially used by anyone who would like to help with the testing.

However the official codeplug has multiple problems, and the final solution will be to have a new CPS for Kai’s firmware, which is designed with the features which Amateur Radio operators need.

So after a few false starts, I have started to build a new CPS from scratch, but to save time re-inventing the wheel, I’m going to initially use some of the screen layouts from the Community CPS.

Jumping in at the deep end, I’ve copied the layout information for the Channels screen into the new CPS, and re-arranged the layout a little, so that the screen is not as tall.

One thing which people will immediately notice in the screengrab below, is that there are a lot of items in this screen which are not in the Community or the official CPS.

This is because they are present in both the official and Community CPS, but were hidden in both these CPS’s

However, since I’m starting almost from scratch again, I thought it was probably worth making all items visible so that we can see whether any of the hidden fields are actually of any use.

Note. I don’t know what things like “Tx Reference Frequency” were intended to do, and I think that the values of these items was probably ignored by the official GD-77 firmware.

So the first task is to determine which of the many items on this screen are needed, and also whether other items, specific to Amateur Radio use are missing.

Some things which are in the official CPS, which I think probably have no use in Amateur Radio are the Privacy and Privacy Group settings. Since as far as I know, transmitting using encryption is specifically forbidden under the terms of most Amateur Radio licences (though some countries may have exceptions to this).
I’m not sure what the Emergency System  setting does or whether its used. I’ve definitely not seen it used on DMR in Australia.

One way forward may be just to specify the minimum usable set of features, especially since Kai’s software currently does not support 75% of the options on this screen, and over time add options as they become available in the firmware.

Key to this upgradability is to move away from the old codeplug data format, where the same binary data which is sent to the radio was also used as the codeplug file saved to disk.

Instead, I’m going to save to disk using XML, because this will allow additional options to be added as time goes by, and yet still allow the CPS to read an existing codeplug XML file – as long as I don’t radically change the structure.
I will also include a format version in the XML itsself, as this would future proof the CPS in case I need to make a more radical change.
Also, using XML makes it much easier for third party tools for read and write the data.

The other thing which I am dealing with from the beginning is support for Linux.
The existing Community CPS does not run on Linux ether using WINE or MONO. I’ve investigated why the existing CPS’s don’t work, but there are a multitude of reasons, and I found it was not practical to modify the Community CPS to run on Linux.
However, because I am starting from scratch, I can test the EXE on Linux, at each stage of the development and ensure it still works OK.

Note. I’m still going to write this using C# in Microsoft Visual Studio, using the DotNet framework, because this is what the Community CPS and official CPS is written in, but I will take care not to use any features which are incompatible with Linux.

This may mean that the “tree view” component, used on the left side of the CPS can’t be used, since I saw some errors in the Community CPS on Linux that seemed to be caused by the tree-view.

But I’m not sure whether a tree-view is necessary. And even if it is, there is an official Microsoft tree-view component, which is part of DotNet, which can be used instead, albeit I don’t think it looks as good.

Anyway, before diving straight in, and starting to write the new CPS, I’m going to download the CPS for a few other radios, and see if there are any better ways to display the data etc.

I have a feeling that its going to take quite a long time to write the new CPS, especially since I’m also writing the GUI and the codeplug interface for Kai’s firmware, but I know there are a few other people out there with C# Visual Studio programming experience, so with a bit of luck I may be able to get some help with this.

Work to develop a new CPS for DG4KLU’s open source GD-77 firmware is progressing rather slowly, because I’ve had other things to do, including fixing some bugs in the firmware.

But after discussing the requirements with a few people, I’ve designed this basic data structure.

I’m not sure if I’ve included all the necessary attributes of a channel, for use on both DMR and FM, but I think its probably good enough to perhaps start the CPS and firmware programming.

For those unfamiliar with database design, I’ve structure the data, each of the blocks in the diagram are called a Table.

The tables, which all DMR users will be familiar with are the Channel, Contact and the Scanlist.

I’ve renamed the Zone to be a channel group, because I think that the term Zone is not very applicable to Amateur Radio use, where we would be more likely to group channels by their frequency band, or their mode (DMR / FM) or some other criteria, rather than by geographical area.

However if this is a name change too far, I could easily rename the Channel Group back to Zone. Since the struture of the data would be the same regardless of the name given to groups of channels.

The other Table which I have renamed is the RxGroup, which I had to rename to TRxGroup, because this group will need to control both the Tx and Rx Talkgroup used by the radio.

I have retained the “Contact” for DMR channels, but I’ve renamed it to ChannelDMRTG, because I think this more accurately describes how Amateur Radio operators use the “Contact” field in the existing GD-77 CPS, where they normally transmit on a TalkGroup, rather than to an individual contract.

This does not rule out the DMR TG being set to a Contact which is a Private Call, so I’m still undecided about what name to give this.

So that the new CPS and firmware, is not constrained to a specific number of Channels per ChGroup (aka zone), I have added intermediate tables, like Channels2ChGroup.

Likewise for Channels2Scanlist, and Contacts2TRxGroup

The only limiting factor will be the total overall size of the database which will need to be uploaded to the radio, but since we will no longer need to duplicate the same DMR channel for every TG that is used on that channel, this drastically reduces the number of channels that are required.

So even though the GD-77 only has just over 1M byte of storage for both the codeplug and the DMR ID database, it limitation will only be on the number of DMR ID’s that can be stored.

Hopefully as time goes by and Talker Alias becomes better supported by other radios and networks, the need for the DMR ID database will reduce, so that the 1Mb memory in the GD-77 lo longer becomes a major limitation.

In fact, I’ve already started work on supporting Talker Alias display in Kai’s firmware.

Its possible that I have overlooked something which I need to store, so I’d appreciate any comments on both the structure, table names and also the individual items in each table.

This story starts a few days ago, when the Australian DMR MARC based network temporarily cut off access to hotspots.

Like many other people I switched to using Brandmeister while the DMR MARC server was offline, but I noticed that my “Last Heard” screen in Kai’s open source GD-77 firmware was behaving very oddly.

Initially the Last Heard screen would display the callsign and name as usual, but after about 1 second the display would update to show a completely different ID, and after another second it would display another different ID number, before finally returning back to displaying the callsign and name.

This process seemed to be in a loop of 3 different IDs.

The effect only happened on my Last Heard screen, and does not manifest itself on the Channel or VFO screens, and also is not a problem in the official GD-77 firmware.

To work out what was going on I added some programming code to write the contents of the DMR data header to a debugging terminal, and I immediately noticed something strange was happening.

Normally the DMR Data header looks like this

00 00 00 00 00 5B 2F 65 11 40 AF 2C

which breaks down to

00 00 00     I didn’t know the meaning of these bytes but they were always 00 00 00 on DMR MARC

00 00 5B     This is the talkgroup number in hexidecimal. In this case 0x5B = 91 (Brandmeister Worldwide)

2F 65 11     This is the stations ID number which in this case happens to be 3106065 as the station was KJ6QBM

40 AF 2C    I don’t know what these bytes contain, but it seems to be different for each station. (I’m sure some of you clever people can tell me what these are for !)

Anyway. On Brandmeister, the data stream I observed looked like this.

Note. I’ve added padding bytes of 00 00 00 00 at the end as it makes it easier for me to put the data into this post, as I used the HxD hexidecimal editor to look at the data because it puts the ASCII text character for each byte at the end of the line

00 00 00 00 00 5B 2F 65 11 40 AF 2C 00 00 00 00 …..[/e.@¯,….
00 00 00 00 00 5B 2F 65 11 40 AF 2C 00 00 00 00 …..[/e.@¯,….
00 00 00 00 00 5B 2F 65 11 40 AF 2C 00 00 00 00 …..[/e.@¯,….
00 00 00 00 00 5B 2F 65 11 40 AF 2C 00 00 00 00 …..[/e.@¯,….
00 00 00 00 00 5B 2F 65 11 40 AF 2C 00 00 00 00 …..[/e.@¯,….
00 00 00 00 00 5B 2F 65 11 40 AF 2C 00 00 00 00 …..[/e.@¯,….
04 00 56 4B 4A 36 51 42 4D A8 AF 2C 00 00 00 00 ..VKJ6QBM¨¯,….
04 00 56 4B 4A 36 51 42 4D A8 AF 2C 00 00 00 00 ..VKJ6QBM¨¯,….
04 00 56 4B 4A 36 51 42 4D A8 AF 2C 00 00 00 00 ..VKJ6QBM¨¯,….
04 00 56 4B 4A 36 51 42 4D A8 AF 2C 00 00 00 00 ..VKJ6QBM¨¯,….
04 00 56 4B 4A 36 51 42 4D A8 AF 2C 00 00 00 00 ..VKJ6QBM¨¯,….
04 00 56 4B 4A 36 51 42 4D A8 AF 2C 00 00 00 00 ..VKJ6QBM¨¯,….
00 00 00 00 00 5B 2F 65 11 40 AF 2C 00 00 00 00 …..[/e.@¯,….
00 00 00 00 00 5B 2F 65 11 40 AF 2C 00 00 00 00 …..[/e.@¯,….
00 00 00 00 00 5B 2F 65 11 40 AF 2C 00 00 00 00 …..[/e.@¯,….
00 00 00 00 00 5B 2F 65 11 40 AF 2C 00 00 00 00 …..[/e.@¯,….
00 00 00 00 00 5B 2F 65 11 40 AF 2C 00 00 00 00 …..[/e.@¯,….
00 00 00 00 00 5B 2F 65 11 40 AF 2C 00 00 00 00 …..[/e.@¯,….
05 00 20 53 65 61 6E 00 00 C8 AF 2C 00 00 00 00 .. Sean..ȯ,….
05 00 20 53 65 61 6E 00 00 C8 AF 2C 00 00 00 00 .. Sean..ȯ,….
05 00 20 53 65 61 6E 00 00 C8 AF 2C 00 00 00 00 .. Sean..ȯ,….
05 00 20 53 65 61 6E 00 00 C8 AF 2C 00 00 00 00 .. Sean..ȯ,….
05 00 20 53 65 61 6E 00 00 C8 AF 2C 00 00 00 00 .. Sean..ȯ,….
05 00 20 53 65 61 6E 00 00 C8 AF 2C 00 00 00 00 .. Sean..ȯ,….
00 00 00 00 00 5B 2F 65 11 40 AF 2C 00 00 00 00 …..[/e.@¯,….
00 00 00 00 00 5B 2F 65 11 40 AF 2C 00 00 00 00 …..[/e.@¯,….
00 00 00 00 00 5B 2F 65 11 40 AF 2C 00 00 00 00 …..[/e.@¯,….
00 00 00 00 00 5B 2F 65 11 40 AF 2C 00 00 00 00 …..[/e.@¯,….
00 00 00 00 00 5B 2F 65 11 40 AF 2C 00 00 00 00 …..[/e.@¯,….
00 00 00 00 00 5B 2F 65 11 40 AF 2C 00 00 00 00 …..[/e.@¯,….
04 00 56 4B 4A 36 51 42 4D A8 AF 2C 00 00 00 00 ..VKJ6QBM¨¯,….
04 00 56 4B 4A 36 51 42 4D A8 AF 2C 00 00 00 00 ..VKJ6QBM¨¯,….
04 00 56 4B 4A 36 51 42 4D A8 AF 2C 00 00 00 00 ..VKJ6QBM¨¯,….
04 00 56 4B 4A 36 51 42 4D A8 AF 2C 00 00 00 00 ..VKJ6QBM¨¯,….
04 00 56 4B 4A 36 51 42 4D A8 AF 2C 00 00 00 00 ..VKJ6QBM¨¯,….
04 00 56 4B 4A 36 51 42 4D A8 AF 2C 00 00 00 00 ..VKJ6QBM¨¯,….

Then the pattern repeats from the beginning

I realised that Brandmeister must be sending Talker Alias data as outlined in the ETSI DMR specification

https://www.etsi.org/deliver/etsi_ts/102300_102399/10236102/02.03.01_60/ts_10236102v020301p.pdf

on page 52.

Note. The spec does not make clear precisely how the data is sent.

There is a page about TA on Brandmeister

https://wiki.brandmeister.network/index.php/Talker_Alias

But again, there aren’t any technical details of the format of this data; so I set about reverse engineering a solution based on the data I was observing.

The most noticeable thing is that the first byte seems to be either 00 or 04 or 05, and when the first byte is 00 the rest of the data is the TG and DMR ID as normal, however if the data starts with 04, the data seems to contain the callsign in ASCII text.

Note. Ignore the “K” in front of the “KJ6QBM”, this initially confused me into thinking this was a VK station, but its a KJ station, and the “V” character is just the hexidecimal value 0x56, which just happens to be in the ASCII character range.

This value isn’t always 56, it often contains completely different numbers, and currently I don’t know what this value means, however its not important, since I know the callsign is always sent from the 4th byte onwards, and seems to be a maximum of 6 characters (Though I think in theory it could be up to 7 characters)

In a similar way, if the first byte contains 05, there is some text that is sent from the 3rd byte onwards, for the next 7 bytes.

For KJ6QBM, the only data that I observed was for types 00, 04 and 05, however for other stations I observed additional data types of 06 and 07.
For example, for G6LNV

04 00 6A 47 36 4C 4E 56 20 58 FB 49 00 00 00 00  ..jG6LNV XûI….

05 00 44 4D 52 20 49 44 3A E8 FB 49 00 00 00 00  ..DMR ID:èûI….

06 00 20 32 33 34 34 34 36 40 FB 49 00 00 00 00  .. 234446@ûI….

07 00 34 00 00 00 00 00 00 E0 FB 49 00 00 00 00  ..4……àûI….

I think the text “DMR ID: 2344464” is being is either being automatically generated by Brandmeister or by this stations radio.

Anyway. Armed with this new knowledge, I set about modifying Kai’s firmware so that it could handle DMR traffic which contained Talker Alias data, and after an email discussion with Colin G4EML, I decided to a single text buffer large enough to store the total number of characters that can be sent in all 4 types of data block, and then to copy each block of text into the correct part of the large buffer as it arrives.

Additionally, since the same block of data gets sent repeatedly, I first check whether data for that block number has already been received and if it has, I don’t need to waste the CPU’s time, copying the data into the large buffer.

Currently the overall algorithm I developed works like this.

When a non TA data block is received, i.e one containing the TG and DMR ID, I check if this station has been heard before; in that its in the last 16 station log I use for the Last Heard screen.

If the ID is not in the log, I add it to the log, and attempt to lookup the ID in the DMR ID database that I loaded into the radio. The screen then displays either the Callsign and name from the database or simply the ID number.

As an example, I was listening on TG91 and the radio initially displayed this ID number, because the ID was not in the DMR ID database in the radio

After around half a second, the radio receives the first block of Talker Alias data (block code 04), which on Brandmeister always seems to contain the station’s callsign.

And the firmware automatically updates the screen to show the updated information.

After about another half a second, the radio receives another TA block type (block code 05), which is “Block 2” of the data
(In this case the I think the station has manually entered their name into the Brandmeister “SelfCare” APRS screen)

and the firmware puts this new data into the appropriate location in the master TA buffer and updates the screen, to show the full extend of the TA memory, which now contains

“JL1WCW Norio”

This transmission only contained block code 04 and 05, so, after this the display did not change as the station continued to transmit

Once the station stops transmitting, the screen returns back to displaying the information about the channel, but if the same station transmits again, their TA data is still stored in the Last Heard log, and the screen immediately shows the TA data that it has already received.

Initially I designed my Talker Alias display algorithm to prioritise the TA information instead of the DMR ID database information (loaded into the radio), however I’ve found that the TA data from Brandmeister is not very consistent and sometimes have entered their callsign into the APRS text , so it simply displays the callsign twice, and also that the TA often contains the Text DMR ID:xxxxx, which IMHO is completely pointless, since the DMR data already sends the ID as part of the initial traffic.

So at the moment, I have changed the display algorithm to use the DMR ID database data if the ID is in the data, and if not to use the TA data if its present.

For anyone using Brandmesiter, I’d advise they login and look at the APRS data section of the SelfCare screen, and simply put their name and possibly their location etc into the APRS data field, because Brandmeister automatically sends the callsign, so there is no need to enter the callsign into the APRS data box.

As this makes the best use of the Talker Alias data that will be sent.

In my case I’ve entered my name and also my location, with Australia being truncated to “Aus” because of the 20 character limit in the APRS Text section.

Note. I’m not sure if there needs to be a space before the name. I’ll need to investigate this, but its difficult to test unless I use both my VK3 and G4 callsigns, since I’m using a simplex hotspot on BM and hence I can’t listen to the traffic back from BM that will have my TA data appended to it.

The Talker Alias display is now working quite well, on both the Channel and VFO screens, however I’m having some problems integrating it into the Last Heard screen.

I can get the Last Heard screen to display the TA data if the station retransmits but updating the data dynamically, is currently causing the firmware to crash and I’ve not had chance to debug why that’s happening.

The open source TA firmware has been tested by a few people, including LB9AB, and he reports that the firmware has a bug where it reboots about once every 2 hours, however I think the reboot problem may not actually be related to the Talker Alias display feature, but is probably caused by another underlying problem in the firmware where there is a buffer overflow in the AMBE codec.

I don’t know for sure what’s going on, but I have noticed some weird things happening when I modify the code, because changes to unrelated parts of the firmware cause the DMR audio to stop completely.

But I think the bug will probably become clearer as time goes by and will need to go onto the bugs list at the present time.

I know people will also ask me whether it would be possible to patch the official Radioddity firmware to support Talker Alias…. I think the answer is, in theory yes, but in practice It could take me weeks of work to add this to the official firmware, and my time is better spent on Kai’s open source firmware, since eventually we will have full DMR and FM transmit and receive functionality, which will render the official firmware redundant

Just a quick post about a bad experience with buying a Vector Network Analyser from AliExpress.

Update 10th July.

Thanks to everyone who has commented. I’ve updated the information in the post and added some more information to the end.

Please see the end of the post for updated information.

Original post starts here…..

The “NanoVNA” VNA arrived this morning, from this vendor on Aliexpress :MAXGEEK Tech Store

But when I opened the package I immediately noticed that the back PCB was scratched, and the screen also had a load of light scratches on it, as if it had been used and then perhaps returned and repaired (I’ve no idea) – See the photos at the bottom of the post.

I immediately raised a dispute with the vendor, and their response, was that the VNA I took the photos of, was not the one that they had sent to me, and I was maliciously claiming to get a refund.

I don’t normally video the opening of these sorts of things, but I guess I should do so in future, but they could of course claim I’ve open the box and resealed it etc

Seeing, the chances of any refund from this supplier look remote, I thought I may as well take the back off the analyser and look inside, I found some other things which could be done better number of serious problems with this device.

Firstly the shielding is missing from the 3 mixer sections, its obvious from the PCB that there should be shielding.

And I noticed that the are NXP SA602 rather than the SA612, as specified in the original design.

The SA602 is only rated to 45Mhz, so despite the analyser being sold as a 900Mhz device, it would really only function on HF.

Even if it was fitted with SA612’s, they are only rated to 500Mhz, which is half the claimed performance of the device

Following comments from lots of knowledgeable readers. I see that I was incorrect in my diagnosis, that the mixer chips would not be usable above 45Mhz.

The datasheets for the SA602 can be downloaded from here   https://www.nxp.com/docs/en/data-sheet/SA602A.pdf  and the SA612 from here https://www.nxp.com/docs/en/data-sheet/SA612A.pdf

Both the SA602 and SA612 seem to have similar specifications, but the data sheet for the SA612 introduction specifically mentions 500Mhz, but the SA602 didn’t.

I presume there was a reason that the original design used the SA612 rather than the SA602, but this could purely be something to do with availability.
I used to assume that devices with higher numbers in their model name, have a better specification, but I have since learnt from experience, that this isn’t always the case.

I had initially intended to replace the mixers with the SA612, and I have ordered them, however I may not end up replacing them if the analyzer seems to be function reasonable well using the SA602’s

I’m still going to make some shielding for the mixers, from some thin copper sheet, and tack that in place with a few points of solder

Updates 10th July

Doing some more research, and the original design is on github https://github.com/ttrftech/NanoVNA

https://github.com/ttrftech/NanoVNA/raw/master/doc/nanovna-sch.pdf

With links to the original manufacturer, who unfortunately seems to no longer make them,

https://ttrf.tk/posts/2016-11-12-tiny-vector-network-analyzer-nanovna-get-work-with-lcd/

I also found this post, by the original designer

https://groups.io/g/nanovna-users/topic/32309232?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,32309232

Which shows the original design and the need for shielding

It also shows what they consider to be the “Bad clone” – which is the one I have.

I’ve no idea what makes the other clone worse than mine, so it would be interesting to see some photos of the PCB from that type.

Thinking about the problem with the display. My best guess is that they are using recycled / recovered screens, taken from other equipment.

I looked at a few videos on youtube, and I’m not sure if the analyser in this video has a plastic protector on it,  https://www.youtube.com/watch?v=fGO74yqDRe4

But it looks like it’s not in good condition.

Mine didn’t come with the plastic peel off, screen protector strip, but even if it did, I’ve had instances where I’ve received other LCD screens (e.g Nokia 5110 screens), which were supposed to be new, but which were obviously used, and had burn in of a logo or the date etc in the center of the screen, and yet still had a screen protector on it.

The recyclers seem to just remove the screens, and stick a new plastic protector on them. They don’t even bother to clean the screen before applying the protector, probably because that costs time and money.

Another minor problem with my device is the push button , jog control seems to be partially defective. This could be because the unit is not new, or it could just be a manufacturing fault, its impossible to tell.

One interesting thing I noticed, is that the PCB seems to have an unpopulated set of PCB pads, which looks like its for a micro SD socket.

The original design, seems to show the SD card as used, so it may not be supported in the firmware.

Anyway. I’ll continue with my investigation into this device

I’ve noticed over the last couple of months that its becoming increasingly difficult for Amateurs in Australia to buy a whole swathe of Chinese made radios.

For example on AliExpress, on some radios, as soon as I select the delivery country of Australia, I get a message saying that the vendor doesn’t ship to Australia

I’ve heard anecdotal reports that this seems to apply to radios from all the major Chinese manufacturers including TYT, Baofeng and Radioddity, but possibly this may only apply to Australian buyers.

Its not totally impossible to buy these radios, but its becoming difficult and increasingly expensive.

For example on eBay Australia the cheapest price for the Radioddity GD-77 is $169.99 AUD (approximately $120 US Dollars)

Whereas on eBay.com (USA), the same radio is available for around $80.

I’m not sure if this its just that suppliers have decided that its the new Australian taxation laws, which appear to require any overseas company selling to customers in Australia to register with the Australian Tax Office, (ATO) and collect GST on behalf of the ATO, which is putting companies off selling to Australia.

Or whether it that Australia is a small marketplace and its not worth the trouble.

Or perhaps whether this is a much wider problem which is possibly being caused by the current trade battles going on across the world.

Or the FCC changes in the USA

etc

But the end result is that the ubiquitous Chinese made handheld radios, that most of us now use, seem to be slowly becoming more of a rarity

I’m extremely pleased to announce that the open source firmware for the GD-77, being developed by Kai DG4KLU and myself, has now reached its first major milestone, and we’ve decided to call the firmware…

Thanks to some more incredible work by Kai, the OpenGD77 firmware now operates as a DMR Tier 1 radio on both receive and also on transmit, as well as a FM transceiver.

This is the culmination of many months work by Kai to reverse engineer how to control the DMR DSP chip used in the GD-77, and I will only be able to briefly cover the many aspects of the firmware.

Firstly, its important at this point to explain what DMR Tier 1 is, and what the firmware can and can’t do.

1. The firmware only works on DMR with simplex hotspots or to other DMR radios for simplex contacts.
   

   This is because the firmware currently does not support sending the “Wake-up” transmission pulses required by a Tier 2 repeater (including duplex hotspots), and does not synchronise with the carrier signal sent by a Tier 2 repeater.The next phase of the project will be to get full DMR Tier 2 working, and this work is now the priority for Kai.However DMR mode can be used with a simplex hotspot and for DMR simplex operation, and I have been using it like this for around 2 weeks, as have the beta testers, with no major problems.

2. FM reception and transmission works.
   

   This includes repeater operation using CTCSS on both Tx and Rx.

3. On DMR, only Talk Group “calls” are currently possible
   

   We have not had time to implement the Private Call functionality, however I don’t think that it would be difficult.

4. DMR Text messages are not currently supported
   

   Messages seem to be handled differently from voice data by the DMR DSP chip, so we will need to investigate how to support this after the Tier 2 work is complete.

5. The official, or Community CPS does not work with the new firmware
   I am currently updating the Community CPS, and hope to have it working in a few days.
   But in the mean time, the firmware can read the existing codeplug in the radio.

Now onto what’s great about the OpenGD77 firmware…

Primarily its open source.
This allows us to write the firmware so that the radio operates in a way we want it to, specifically for Ham radio use.

It will allow us to do things which other DMR radios don’t do, e.g. potentially in the future, cross band operation to duplex hotspots. Or possibly use the radio as a high power hotspot by using the USB programming cable as a comms interface to PiStar.So that we are now only limited by what the raw hardware can and can’t do, and by our own imagination, and not by the firmware which was written specifically for commercial users, whose requirements are a lot different from Ham radio use.

We have already been able to move away from the work-arounds that are necessary when using the official firmware.

Most notably there is no longer any need to have multiple channels with the same frequency, but with different Talk Groups.

The OpenGD77 firmware uses the Rx Group list assigned to a “Channel”, as both a Rx and also a Tx group list.

On the keypad, the left and right arrow keys are used to cycle through the TGs in the Group list.

In Channel mode, the up and down arrow keys change channel, as in the official firmware.

This functionality significantly reduces the number of “Channels” that are required, and also simplifies the structure of the codeplug.

You can see in my codeplug,that I now only have 1 channel per repeater.

The Zones can then be used to group of all the repeaters in a particular city or region. For Example I have all the DMR repeaters in the state of Victoria in the same Zone.

Looking at the Rx Group Lists, I now only have 3 groups: one for DMR_MARC for the repeaters, and one for Brandmeister which I use via my hotspot, and another for BM UK.

I don’t have time, at the moment, to completely document all the functionality of the firmware, so I have made a video describing it’s operation, which is available on Youtube

Note.

I made this video a few days ago, and since then we’ve made a number of improvements:
For example, in the video I say that the PA is not being pulsed every 30ms in DMR mode, but it is now being pulsed.

But on the whole the video will give an overview of the menus and general operation of the radio with this firmware installed.

All the source code and an install-able firmware file is available on Github in the HamDV account

https://github.com/hamdv

https://github.com/hamdv/OpenGD77

Please note.

This is still experimental firmware, and you install it at your own risk.

Although multiple people have tested the firmware, there is always a chance that installing non-official firmware could potentially damage or completely “brick” your radio.

The firmware is intended to be non-invasive, and does not change the codeplug or other settings used by the official firmware, so it is normally possible to reload the official firmware, with no ill effects to the radio.

If anyone is interesting in installing and testing this firmware, please leave a comment, and I will contact you via emial to answer any questions etc.

I plan to do some follow up posts, describing various aspects of the firmware, over the next week, but I’m also trying to get the CPS working, so the blog posts may need to wait…

Finally, I’d like to thank the testers including VK7ZCR, W1HRS, LB9AB, G4EML, VK4JWT and anyone else who I’ve forgot to mention.

And of course to thank Kai again for his continued work to produce this amazing firmware.

Guys

The OpenGD77 project is massive undertaking and if possible I’d like to get some help from the readers of blog on a wide variety of related topics.

Top of my Help wanted list is for the Hotspot mode which we hope to develop for the OpenGD77

https://github.com/hamdv/OpenGD77/issues/10

Hotspot mode will allow the GD-77 running the OpenGD77 firmware to be connected to a PiStar device, via USB using its programming cable, to act in the same way as the simplex MMDVM “Hat” board – For DMR only

I have analysed data serial data protocol between MMDVMHost and the MMDVM_HS firmware running in the “Hat”, and I understand the general protocol, and will soon start to write the initialisation and some other communication functions.

However, the actual DMR data traffic between the MMDVM_HS and MMDVMHost looks nothing like raw DMR data

MMDVM_HS seems to do some strange bit swapping processing of its internal DMR data before sending it,via Serial, to MMDVM_Host, but I don’t know what the internal data inside MMDVM_HS looks like, unless I recompile it and add some debugging statements to write the data out to the Nextion port and then connect that port to my PC via a USB.

This is a lot of additional work and will take quiet a lot of time simply to setup to compile MMDVM_HS on my RPi etc

I’ve tried to contact Andy CA6JAU who wrote MMDVM_HS to ask for information on the internal DMR data format in MMDVM_HS, but I’ve not been able to contact him, I’ve also tried to get in contact with Jonathan G4KLX for help from the MMDVMHost side of things, but not had any luck with that either.

I’m sure we’Il will eventually be able to get this working, but I don’t have any detailed knowledge of how MMDVMHost or MMDVM_HS work, and potentially it may not be possible to interface the OpenGD77 firmware with the normal version of MMDVMHost and we may need to develop a modified version.

If we needed a custom version of MMDVMHost it would be more difficult for people to use the entire system, because they’d need to run a custom version of PiStar, which could then not easily be updated, unless Andy Taylor could be persuaded to include a custom version of MMDVMHost in PiStar for the OpenGD77…

So I’d like to put a general call out for anyone who could give use some ideas about which approach we’d need to take in order to get Hotspot mode working as soon as possible.

Just a quick post for anyone testing the OpenGD77 firmware

I’ve now finished adding some initial support for the OpenGD77 into the Community CPS, and I’ve created a special version of the installer for the version with these features, which can be downloaded from here

https://github.com/rogerclarkmelbourne/radioddity_gd-77_cps/raw/OpenGD77_Comms/installer/RadioddityGD77CPS31XCommunityEditionInstaller.exe

This version also still supports the official firmware, using the normal Read and Write buttons on the main screen

As well as the updated installer, you will need to install a driver, because the OpenGD77 operates as Serial USB device.

The 2 files that are needed to install the driver are here

https://github.com/hamdv/OpenGD77/tree/master/OpenGD77CommDriver

Once the driver is installed, the Windows device manager should show the “OpenGD77” in the “ports” section.

In the CPS , there is a new menu item under the Extras menu for OpenGD77 Support, which opens this window

From here you can backup, both the internal 64k EEPOM and the 1 mega byte Flash chip, as well as Reading and Writing the codeplug.

Before Writing a codeplug to the radio, you should backup both the EEPROM and Flash chip, and save the files somewhere safe, in case something goes wrong in the future and you need to restore the data.

To read the codeplug,press the “Read codeplug” button, wait for all 3 data sections to download, and then close the OpenGD77 Support window.

To write a codeplug, First put the radio into FM mode, by pressing the star key if you are in DMR mode, on either the Channel or VFO screen.
Then just press the “Write codeplug” button.

If you change the VFO settings, you’ll then need to go into the Utilities menu and select the option to do a “Fact reset”, as this is currently the only way to reload the VFO data into the non-volatile settings that the firmware uses.

DMR ID support has also been added, in the DMR ID window, where there is an extra button at the bottom, labelled “Write to OpenGD77”

Currently there is no indication in the OpenGD77 firmware that the codeplug is being read or written, but I think we’ll need to add a screen like the official firmware has, and we’ll also need to have a better way to reload the VFO paramaters from the updated codeplug.

At the moment, things are bit untidy, but at least it works, and I’ll clean up the user interface at a later date when I don’t have so much programming to do on the OpenGD77 firmware itself.

I woke up this morning to find a load of emails from my hosting company, Hostgator, letting me know that my entire hosting package had been locked because it had gone over its CPU usage quota.

Checking the logs, the problem was being caused by the stm32duino website requiring more CPU capacity than Hostgator can provide on my currently hosting package.

After some communication with Hostgator I have been able to re-activate my the blog part of my hosting, but not the other domains, as they would continue to overload the CPU.

Hopefully, with just my blog enabled on the web server, it should begin to run a little faster and hopefully I will not suffer another outage.

For the last 6 weeks, I’ve been intensively working on the Hotspot mode as part of the OpenGD77 firmware, and it is now finally with the Beta testers in Australia, Europe and the USA.

Note. Currently firmware seems to be stable but not completely bug free, so I am limiting its use to the Beta testers.

Hotspot mode converts a Radioddity GD-77, running the OpenGD77 firmware, into a DMR ONLY high power hotspot when its connected to a Raspberry Pi running PiStar.

No other hardware is required, just the RPi and the GD-77

In this photo I’m using a Raspberry Pi 3B+, but I’ve also tested with a RPi Zero W and it works just as well.

The GD-77 is connected to the RPi via its USB programming cable, and the only change that needs to be made in PiStar, is to change the modem type to any of the “Zumspot” compatible modem types e.g. the “Zumspot Libre”

One thing however you won’t see unless you modify you copy of PiStar is the “modem” name being displayed in the PiStar dashboard, because PiStar only supports displaying the firmware version for the specific “modems” in the list

I have modified my copy of PiStar to add the OpenGD77 Hotspot, and I presume if enough people eventually use their GD-77’s as hotspots, Andy may add the OpenGD77 Hotspot as a new modem type in PiStar, so that it will display correctly.

I’ve done rather shaky video showing the OpenGD77 Hotspot mode working with a Rasperry Pi Zero.

For those of you interested in the technical details, please read on..

Conceptually both Kai and I assumed that adding Hotspot mode functionality to the OpenGD77 firmware should not be too complicated, because we can access the DMR data from any transmission which the GD-77 receives, and can also transmit and audio and other data via DMR RF.

Unfortunately our assumptions about the difficulty in writing Hotspot mode were not correct, and a great deal of new code needed to be added to the OpenGD77 firmware to support Hotspot mode.

Before I continue, I think its worthwhile explaining how a normal PiStar hotspot works.

At the core of PiStar is a program called MMDVMHost, which was written my Jonathan G4LKX,  which interfaces the original MMDVM modem hardware, to the Internet servers for DMR and other protocols.

MMDVMHost communicates with the “modem” using its own serial protocol, originally via USB Serial but now more commonly via GPIO serial on a Raspberry Pi to a MMDVM_HS Hat board, aka Jumbospot.

MMDVMHost handles the server connectivity and a loads of other functions, to seamlessly transfer the data, to and from the “modem” board.

I had assumed that the data being set between the “modem” hardware and MMDVMHost contained high level DMR data, including the transmitting stations DMR ID number and the Talkgroup number as well as the AMBE compressed audio data bytes.  However, when intercepted some of the serial data being sent between the Raspberry Pi and my duplex hat board, (running in simplex mode), I realised that I was at least partially wrong about how MMDVMHost and MMDVM (or MMDVM_HS) work.

I expected to see data bytes containing my DMR ID (5053238) , as well as bytes containing the Talkgroup I was using (505), but the data between the hotspot board and the RPi did not seem to contain that data at all.

After some research, I found out that the data is in the  “On Air” format, and that modem (Hat etc) boards only do minimal processing of the DMR 4FSK data which they receive before sending it to MMDVMHost

MMDVMHost then creates a packet of network data, which is a header containing the Source and Destination ID’s etc, followed by the raw “On Air” data.

At the other end of the system, e.g. any hotspots connected to the same Talkgroup; MMDVMHost, sends the On Air portion of the network packet of data to the modem, and the modem basically just remodulates the On Air data to 4FSK and transmits it.

The GD-77 hardware however, works completely differently….

The GD-77 has a dedicated IC ( Hongrui HR-C6000)  which performs both the 4FSK demodulation and also completely decodes the DMR “On Air” protocol, so that the CPU in the GD-77 does not need to do this processing.

HR-C6000

Note. This is the same IC that is used in radios like the TYT MD-380 etc and I  Baofeng RD-5R and Baofeng DM-1801 etc

Except the MD-380 uses the older version, called the HR-C5000

Hence the only way to interface the OpenGD77 firmware to MMDVMHost was for the OpenGD77 firmware to generate the “On Air” format data that MMDVMHost and every other hotspot expected to receive.

This would have been an incredibly difficult task, except that MMDVMHost contains all the functionality that I needed to both encode to the “On Air” format and also to decode the “On Air” format, and because MMDVMHost is open source, I was able to incorporate the majority of its DMR processing functionality, into the OpenGD77 firmware.

Unfortunately, even though MMDVMHost contained all the necessary functionality, MMDVMHost does not use the functionality in the way that I needed to. For example,  It normally decodes the “On Air” data, rather than encoding it, so I had to work out which bits of MMDVMHost I needed to encorporate in the OpenGD77 firmware and also how to use those parts, to do almost the reverse of what they normally do.

And just to complicate things, MMDVMHost is written in the C++ language in an Object Orientated way, whereas the OpenGD77 firmware uses the C programming language which does not support Objects or a number of other features of C++, like function overloading which MMDVMHost makes use of.

So all the source code files needed to be “ported” from C++ to C by making changes to around 50% of the code.

Consequentially, it took me 3 or 4 weeks to find the parts of the functionality in MMDVMHost which I needed to port, and to port them and integrate them into the OpenGD77 firmware.

Additionally, I had to implement the functionality to communicate via MMDVHost’s serial protocol, as well as integrate the new functionality into the existing OpenGD77 Tx and Rx functionality.

Needless to say this was quite a complex task, but after 50 hours of work, I was able to receive network data from MMDVMHost and get the GD-77 to transmit it via RF.

It took me another week to write the functionality so that the received RF DMR signal was sent to MMDVHost, and yet another week to add some missing functionality like Private Calling, and also the transmission of Talker Alias data when received from MMDVMHost as embedded data in the Voice audio frames.

Various versions of the firmware have been with the Beta testers for about a week, and they are still uncovering a few bugs, so currently I don’t feel its stable enough for general release. However I plan to make it part of the OpenGD77 firmware in the fullness of time.

BTW.

If anyone has some specific questions, please post comments, as I have glossed over a lot of the complex technical details of how I made this work, as that would probably be incredibly tedious and also take many hours to document

The configuration screen having a new Modem option of OpenGD77 DMR hotspot (USB)

And the Dashboard now displays the name and the firmware version

A note to the Beta testers.

Your versions won’t display the version number correctly, as I only added this today and I have not send out an update with the version number included.

I’ve been making some enhancements to Hotspot mode today, so that the display on the GD77 uses the DMR ID database to look up the callsign and name, for both Rx and Tx functionality

I’m also working to add power control via PiStar, but for that to work, I also need to add the general functionality to read the High and Low power PA drive values from the calibration data in the Flash memory and also build a look-up table to convert from required power values in milliWatts to PA drive values.

Because as you can see from the graph below, the relationship between PA drive level (voltage) and power output in mW is not linear.

The blue line in the graph, is record values from VK4JWT’s radio on 437.5 and the green line was my attempt to calculate the value using a quadratic equation.

However, I think its going to be easier to manually build a look-up table an interpolate between values

One other thing I noticed is that the power calibration on my radios is not that accurate. One radio was putting out 4.6W when it should have been 5W, so I’m not sure if the factory power calibration values are that accurate.

I think the OpenGD77 Hotspot mode firmware is probably stable enough for more people to Beta test it, so I am making it publicly available for download via this link on my blog

OpenGD77_20190906_Hotspot.0.0.2

This firmware can be loaded onto the GD77 using the official firmware loader. (after you extract it from the Zip file)

Please Note.

1. This firmware is still in the early stages of development.
2. You use it at your own risk.
3. It may not be completely stable and is likely to have bugs.
4. Using high power settings may overheat the PA in the radio, because the radio is not designed to be constantly transmitting.

Default power in the OpenGD77 firmware is approximately 1W, and this is the value that will be used by the Hotspot unless you change either the Power (PA drive) value in the Utilities menu, or you change the RF Level setting in PiStar’s Expert -> MMDVMHost settings.

If you change the power setting in PiStar to any other value apart from the default value of 100%, the firmware will use the value from PiStar.

Hence 99% will give almost 5W, which is unsustainable over a long period of time.

0% will almost turn the PA off completely, but you will find at short distances that the 5mW produced by the AT-1846S  Tx/Rx chip in the GD-77 can still be received.

The power display in Hotspot mode, is currently only a rough approximation of power, as its actually the percentage of PA drive, multiplied by 5000mW to give a mW figure.

However since the PA output is non linear with respect to PA drive voltage this value is not accurate.

If you want to set your Hotspot to a specific power level, which you measure using your own power meter.

1. Turn off PiStar (Power off)
2. Exit from Hotspot mode using the red menu key.
3. The radio will probably now be in VFO mode.
4. Connect a power meter
5. Press the * button and look at the top left of the display to confirm the radio is in FM mode (or press * again until you toggle into FM mode)
6. Go into the Utilities menu, and select a PA drive setting (approx 1700 gives 1W)
7. Adjust the value by pressing the left and right buttons.
8. Press the PTT to transmit in FM and confirm the power level
9. When you are happy with the power level. Press the green menu key.
10. Turn the GD77 off and on again, go back into the Utilities menu and confirm the power setting has been saved
11. Exit back to the VFO (or Channel screen) by pressing the green menu key.
12. Turn PiStar back on, and wait for the radio to enter Hotspot mode.
13. Make sure the RF level is set to 100%, as this will use the value you just assigned in the radio

OpenGD77 User Guide  (Alpha version) is now available as a PDF file for download

Thanks to Alister G0NEF for getting the ball rolling by creating the first draft, which has now been extensively reworked to produce the Alpha version.

Please note.
Since I took the photos, for the User Guide a few days ago, the TimeSlot number and Colour Code number have now been added to the main display and all the photos are now out of date. However I don’t currently have time to re-photo all the screens to show the very latest features on the display.

Also. The User Guide does not cover Hotspot mode yet.

The User Guide can be downloaded from this link

https://github.com/rogerclarkmelbourne/OpenGD77/raw/master/docs/Open%20GD77%20User%20Guide.pdf

Just a reminder about the OpenGD77 project in general

1. This is a non-commercial project.
   I’ve noticed some companies are now offering the OpenGD77 firmware as a $25 additional charge when buying the GD-77, and people may get the impression that this is a commercial software and comes with support and guarantees, which of course its does not; because its experimental open source software with a non-commercial license.Commercial companies profiting from volunteer work is likely to cause the project development to go underground and updates will no longer be available to everyone.
2. The firmware is still highly experimental.
   You use it at your own risk, especially Hotspot mode, where the radio should not be left unattended for long period of time.
3. The firmware does not do everything which the official firmware does
   It currently only supports Tier 1 DMR, so won’t work with duplex hotspots or repeaters, only simplex hotpots and simplex QSO’s.
   It does not support SMS messaging.
   It does not support the Digital Contacts, except for their use as TalkGroups
   etc
4. Its open source
   You are free to download and modify it to suit your own needs, but I can’t provide any support either to help customizing the software for your own needs, or necessarily to fix any bugs you may encounter.

While doing some testing for VK7ZJA this morning, to track down a bug in the official Anytone firmware, I managed to cause the OpenGD77 Hotspot being used by Clayton VK7ZCR to lock-up it was transmitting.

Fabio IZ2BKS had reported this bug to me a few days ago, and I had attempted to fix it, however because I was not able to replicate the bug, the fix I sent to Fabio was based on guessing what was causing the problem, and my guess proved to be wrong.

Clayton VK7ZCR was able to cause my OpenGD77 Hotspot to hang during transmission, and because my hotspot was running in the debugger attached to my PC, I was able to see what the Hotspot was doing when it hung.

The Hotspot hung while waiting for the Tx buffer to re-fill, with DMR frames from the network, but due to a combination of conditions, no DMR data was being sent by MMDVMHost to the OpenGD77 hotspot, and hence the Hotspot stayed permanently in its TX_BUFFERING state.

Normally the TX_BUFFERING state occurs after the OpenGD77 Hotspot receives the Voice Link Connect frames from MMDVMHost, and while its waiting for a few DMR voice frames to arrive and be put into the Tx DMR frame buffer. Then once there are 4 frames in the buffer the GD-77 Tx hardware is turned to start transmitting the DMR audio.

The TX_BUFFER state is also used, if the TX DMR frame buffer has become empty, because the other station has stopped transmitting,  but while the GD-77 Tx hardware is shutting down, and transmitting the 6 mandatory Link Terminator frames , (which takes 360mS to complete).. some more network data then arrives during that 360mS shutdown phase.

Consequentially, if during the Tx shutdown phase, a few extra DMR Voice frames arrives, the Hotspot would go back into TX_BUFFERING state, but would never leave that state, because not enough voice frames would arrive, because the transmission at the other end of the network had actually ended.

To correct this problem I’ve made several changes.

1. I’ve added a 500mS timeout in the TX_BUFFERING state, so that if this timeout is exceeded whilst waiting for data from the network, the Hotspot will reinitialize and go back into Rx mode.
2. Also if PiStar (MMDVMHost) sets the OpenGD77 Hotspot into IDLE mode while its in TX_BUFFERING mode, it immediately goes back into its Rx mode

The combination of these 2 changes seems to have made the Hotspot a lot more robust, and neither Clayton VK7ZCR or I can now replicate the same bug, no matter how quickly or how many times we re-key the PTT, even if we re-key multiple times in quick succession.

All OpenGD77 users should update to the new version (v0.0.5) before they use their OpenGD77 Hotspot again, from my “daily builds” link

https://github.com/rogerclarkmelbourne/OpenGD77/raw/master/firmware_binaries/daily_builds/firmware.sgl

After the update PiStar should show that the version of the Hotspot is now v0.0.5

I’ve made a few small changes to the OpenGD77 firmware and uploaded a new version to the daily builds folder on Github (see the link below)

1. There is a fix to prevent totally incorrect power levels being shown in Hotspot mode, if the PA drive setting in the utility menu was set to values below 775.This was being caused when the calculated power in mW was a negative value.

   I have changed the Hotspot version that is displayed in PiStar to v0.0.51

2. I’ve changed the beep volume setting to be adjustable in 3dB steps rather than the arbitrary percentage values that resulted from the way I was reducing the audio volume by dividing the amplitude by integers between 1 and 10.

   0dB should be approximately the same volume as the official firmware, 3dB will be twice as loud and 6wB will be 4 times as loud.
   The minimum value is -24db which is barely audible above the physical click of the buttons.

   I have also changed the pitch of the key beep to be roughly the same as the pitch in the official firmware.

   Some users will probably need to adjust their beep volume settings again in the Utilities menu.

3. I have also prevented the radio starting to transmit if the PTT is pressed during boot-up or during shutdown.

As usual the firmware can be downloaded from

https://github.com/rogerclarkmelbourne/OpenGD77/raw/master/firmware_binaries/daily_builds/firmware.sgl

Other news

Over the next few weeks I’m going to start investigating how to implement DMR Tier 2.

Colin G4ELM did some initial investigations into what needed to be added to, or changed in the firmware in order to support Tier 2, but discovered that a partial re-write of the existing Tier 1 functionality would be needed before any work on Tier 2 could commence.

I’ve also noticed that the DMR end of transmission appears to be slightly wrong, because there is an additional audio tone after the DMR 4FSK has finished. This seems to indicate the the PA and Tx is being held on after the DMR DSP chip has completely finished sending all the necessary DMR data (Link terminator frames), so I will also be attempting to fix that small problem.

I may still occasionally add enhancements just as light relief from the Tier 2 work, and I will release bug fixes when necessary, but my primary focus will be on DMR Tier 2.

Just a quick post for anyone using the OpenGD77 as a Hotspot connected to BlueDV on the PC

I’ve resolved the problem where BlueDV set both the frequency and power of the hotspot to zero when the “DMR” button was pressed.

The problem was a combination of 2 things.

1. BlueDV seems to send the  Set Frequency command twice. Once when BlueDV initially connects to the radio, and once when the DMR mode is enabled.
   The data in the first Set Frequency command is correct, however the data in the Set Frequency command that is sent when the DMR mode button is enabled seems to be invalid, because the fields which normally contain the Tx and Rx frequencies and also the power, are filled with zeros.

   I’m not sure if this is a bug in BlueDV, or whether there there is a reason the Set Frequency is sent with zero’s for all values, but either way it caused problems in my Hotspot firmware, because I didn’t expect the “host” to send what appears to be invalid data.

2. My Hotspot firmware had a bug, where i used the master Rx and Tx variables to store the data from the Set Frequency command, before I had checked whether the values for Tx frequency and Rx frequency were valid.
   Consequentially, even though I send a reject back to BlueDV when I had decoded the Rx and Tx frequencies, to indicate to BlueDV that I thought the frequencies were not valued, I’d already stored the value of 0Hz into both the master frequency values, and hence why the screen end up showing 0Hz with a small rounding error since the frequency of 0Hz is not valid

I’ve now fixed the bug in my code, and the firmware now ignores the invalid frequencies and power settings sent by the second Set Frequency command.

I’ve changed the Hotspot version number to v0.0.6, and also to save confusion about the overall OpenGD77 firmware version, I’ve removed the master version number which was V0.3.5, from the Firmware info screen and replaced it with my callsign “VK3KYY”, so that its obvious that this firmware is quite different from the last formal release which Kai did from his HamDV account on GitHub.

As I continue with the firmware development, the best indication of the overall firmware version will be the date as show on the Firmware info screen, and I will update the Hotspot version number, visible in PiStar if changes are made to the Hotspot functionality.

This new version of firmware can be downloaded from the same location as the previous version https://github.com/rogerclarkmelbourne/OpenGD77/raw/master/firmware_binaries/daily_builds/firmware.sgl

I have also tested this new version on my Android phone, by following the instructions by Riku OH1E in his Youtube video, and it worked OK. But I did have some occasional problems, where BlueDV seemed to indicate it was receiving a signal from the net but the OpenGD77 did not transmit.

At the moment I don’t have time to investigate why the Android app didn’t work perfectly, because I am focusing my efforts into making the OpenGD77 firmware support DMR Tier2.

Jet another quick post with an update, but this time to the GD-77 Community CPS

I’ve modified the GD-77 Community CPS to include an option to include the Windows Comm port driver needed when using the Community CPS with the OpenGD77 firmware.

By default the CPS installer will run the driver installer when the main part of the installation is complete.

Please note since the CPS is run by default after the installer finishes, the CPS application will obscure the driver installation window. However because the driver installer does not have a user interface this does not affect the operation of the driver installer, it simply means you don’t see it installing.

If for some reason the driver installer fails, it may leave its installation window open, and show an error message, but since I’ve never had a problem with the driver installation, I don’t know for sure what happens under those conditions.

If a GD-77 running the OpenGD77 firmware is connected to the PC when the driver is installed, you should see the Windows notifications in the bottom right of the screen, showing the driver has been installed. However if the GD-77 is not plugged in etc, Windows will not complete the driver installation until you plug in or turn on the GD-77 which is running the OpenGD77 firmware.

The CPS installer should already request Administrator privileges if it needs them, and these privileges will also be used for the driver installer, because they are essential for the driver installation.

The installer is available for download from the usual location https://github.com/rogerclarkmelbourne/radioddity_gd-77_cps/raw/master/installer/RadioddityGD77CPS31XCommunityEditionInstaller.exe

For those who want to know the technical details.

Windows 7 or newer requires “signed” drivers, which has been a major problem to the open source community, because it costs a fortune each year for the certificate etc.
Fortunately Pete Batard thought of a way around this by writing a driver installer library   https://github.com/pbatard/libwdi, which I think creates a self signed certificate for the driver as part of the installation process, and thanks to some work done for the Arduino STM32 project (I’m sorry but I can’t remember who did the work), I was already in possession of a driver installer using libwdi specifically designed to install the USB Serial (USB CDCACM) device driver, which I was then able to reuse for use with the OpenGD77.

For the Arduino STM32 project, the drivers are installed using a Windows bat file, but in this case I’ve effectively put the part of the installation process handled by the bat file into the installer.

If anyone has problems with the driver installation, the driver installer is copied in the Windows Temp folder in a folder called OpenGD77CommDriver and is called wdi-simple.exe

If the driver installer needs to be re-run, this can be done my opening a Command Prompt (CMD) , changing to the %temp%\OpenGD77CommDriver directory and manually running the command

wdi-simple.exe –vid 0x01FC9 –pid 0x0094 –type 3 –name “OpenGD77“

A number of people reported that the latest GD-77 Community CPS installer had a virus in it.

To cut a long story short, this is almost certainly a false positive, but I appreciate that its a big risk installing something which your antivirus has reported as a virus, so I’ve had to revert to the previous version on GitHub, which does not include the driver for the OpenGD77 comm port.

I’ve also copied my original files, that I use to build the installer exe, onto GitHub and also zipped up the Comm port installer exe and bat file

https://github.com/rogerclarkmelbourne/radioddity_gd-77_cps/tree/master/installer

At the moment, there’s not a lot more I can do about this, because the the antivirus companies would rather declare multiple false positives than one false negative.

To try to understand why the installer now seems to be reported as a virus, I did a complete virus scan on my PC using 2 different antivirus packages.Firstly the built in Microsoft Antivirus, and then using Avast Antivirus.

This scan took around 9 hours, multiplied by 2 programs, i.e 18 hours, and I had to leave it going overnight for 2 consecutive days.

None of the individual files which are installed by the are reported as viruses by either antivirus package

Bizarrely, Microsoft Antivirus does not think the installer a virus when InnoSetup initially exports the exe.

It’s only if I upload the exe to GitHub or my Google drive etc, and then download it again, does Microsoft Antivirus decide that not only the file that has just been downloaded is a virus, but also the original file I uploaded is now a virus, and any other copies of the file on my PC.

I’ve found that I don’t even really need to upload and download the file for the exe to be flagged as contain a virus.
All I need to do is to drag the exe into the Google Chrome browser, and it treats the file as if its been downloaded from the web and somehow seems to be either getting Microsoft antivirus to scan it, or possibly Chrome is doing something like sending the exe to Google central for scanning, because when I drag a local file onto google, it takes it at least 15 or 20 seconds before it decides its a virus, and the local virus scanners do not take that long to scan a file.

Doing some research, this seems a common problem for any exe’s which are not digitally signed. But the cost of a digital certificate from a reputable provider is around $500 USD per year, and there is no way I could afford a digital cert, especially as I do all of this for free.

So, at least for the time being, I’m not able to build any new installers for the CPS and people will need to manually install the comm driver.

Now that the Hotspot mode functionality is relatively stable, I’ve switched my efforts to supporting DMR Tier 2 in the OpenGD77 firmware.

Kai (DG4KLU) told me a couple of months ago, that he had been working on the Tier 2 functionality, but was unable to get it to work correctly, and that he no longer had any spare time to work on the OpenGD77 firmware.

Colin G4EML had some time recently to help with the OpenGD77 firmware, did some tests to try to understand how we could move forward with the Tier 2 functionality, but came to the conclusion that there appeared to be fundamental problems with the existing DMR Tier 1 programming code. These problems mainly related to the inaccuracy of the timing control, or possibly because different triggers from the HR-C6000 DMR DSP chip could be processed in the wrong order by the existing DMR programming code.

So I set about doing a major overhaul of Kai’s original DMR code, to resolve the potential problems which Colin had found.

The biggest change was to move all of the code that relates to handling the interrupts from the HR-C6000 from being processed as part a “task” in the Realtime Operating System  (RTOS) which the firmware uses, to being handled by Interrupt Service Routines.

To roughly explain what this means in layman’s terms, the RTOS is set to run the DMR code, once per millisecond. This code checked if the HR-C6000 had flagged that it needed some attention, and then processed that request.

The problem with this system, is that the worst time delay between the HR-C6000 flagging it needs to be dealt with, to it actually being deal with, could be as much as 1 millisecond, and with a protocol like DMR, a 1 millisecond delay may be too much.

Moving the code from the RTOS task to an Interrupt Service Routine, is not just a matter of cutting and pasting the code, because the time that can be spent in an ISR is very small, so that for example its not possible to run the AMBE audio codec from inside the ISR. Also the ISR can’t use any RTOS system functions which are intended to prevent resource conflicts e.g. 2 parts of the firmware accessing the same hardware at the same time, so any potential hardware conflicts need to be handled some other way.

The hardware in question is the HR-C6000 DMR DSP chip its self, which has 3 digital interfaces, ( two SPI buses and a I2S bus), and in practice the only way to prevent bus contention on was to move all the SPI related functionality inside the ISR. Well, actually the initialisation code is not in the ISR, and nor is the code which initially configures the HR-C6000 to go into transmit mode when its completely idle, but when its idle I was able to briefly disable the interrupts so that I can use the SPI bus outside of the ISR’s.

This radical modification of the code took me about two weeks, and at the same time I had to modify a lot of other code related to operating in duplex mode, including changing the Tx / Rx switching system to completely be able to change from Rx to Tx every 30mS while the radio is transmitting, as well as being able to change the Tx / Rx frequencies at the same time, and switching the PA off and pre-amps on etc etc etc.

I finally got the simplex functionality working again, but in the process I broke the Hotspot mode functionality, and it took another day to get that working again.  Currently Hotspot mode may not be 100% stable, as I had a report that it crashed while transmitting after about 6 hours of use. However , since Hotspot mode works OK in the old Tier 1 firmware this is not a priority for me at the moment, and anyone wanting to use Hotspot mode can old the older stable Tier 1 firmware.

After the overhaul, I found I was able to transmit to my duplex hotspot, as long as I woke-up my hotspot using GD-77 running the official firmware.
Strangely I found that I was also able to wake up my local Motorola based repeater, if I transmitted for around half a second and then released my PTT, whereas continuing to hold the PTT and keep talking failed to wake the repeater. In theory the firmware should not be waking the repeater at all.
Kai has now sent me some code he wrote which is designed to wake up a repeater, so I will attempt to integrate his code into my new structure and see if it works, or if I need to make modifications or perhaps write it again from scratch.

What I can’t get working at the moment is the Timeslot selection.
The existing DMR code, which Kai wrote, seems to somehow be locking onto the currently active Timeslot, so that if someone wakes up the repeater by transmitting on Timeslot 2, I’m normally able to have a QSO with them on TS2. But is someone wakes up the repeater and starts to have a QSO on Timeslot 1, the firmware is only able to communicate with them, and not to put a call out on Timeslot 2.

In theory there are several “registers” in the HR-C6000 to determine the current Timeslot that is being received, but these are not working for me, and I suspect that they don’t work unless the HR-C6000 correctly initially locks onto the DMR frames based on their TS code correctly.

Overall, I’m very optimistic that Tier 2 will definitely be possible in the OpenGD77 firmware, but its hard to know now long its going to take me to resolve the remaining issues, as currently I am the only person actively working on the project.