Brent VA7BNB contacted me as his brand new GD-77 seems to have a new version of firmware, which has not been released either to the Beta testers or on the official Radioddity website

Bent tells me that he didn’t receive a disk firmware 3.1.3 on it, so unless one of the beta testers has been sent a copy of 3.1.3 we have no way of getting hold of a copy.

On a possibly related note.

Radioddity also now seems to be selling a version with an inverted video display. Back background with white text.

However I don’t know whether the hardware in the display is the same and this is controlled via the firmware, especially the new firmware.

I guess we’ll find out in the new few weeks when people buy and receive these new versions

Update. 16th May 2018

Apparently, Radioddity have said that 3.1.3 does not contain any new features, but fixes some problems. However they have not said what problems it fixes.

They’ve also said that they do not have an update file for this version at the moment, but will put it on their official website when they have received it themselves.

This seems to imply that Radioddity receive the radios, with the firmware pre-installed, from another company, rather than writing the firmware themselves.

This explains why they often seen unable to fix firmware bugs, and are reluctant to add enhancements, because they their suppliers effectively are the ones who are in control.

I thought it was worth sharing a limitation with the MMDVM DUAL HAT duplex hotspot , which I uncovered today.

I was testing with both DMR and YSF mode enabled, and found that the GD-77 would only connect to the hotspot on a very intermittent basis.

Perhaps 1 in 10 tries would result in the GD-77 connecting.

My initial thought was that the hotspot may not be listening for DMR signals for long enough to detect the call setup data being sent by the GD-77, so I discussed this with Andy CA6JAU via a github issue, and he advised me that its a known “issue” and that I could try increasing the “SCAN_TIME” (hold time) setting in the firmware to see if that improved things, but that it would result in other modes being less responsive.

However before I attempted to change the firmware, and rebuilt it, used another FM receiver to listen to what the GD-77 was doing, and unfortunately it only appears to send one call setup burst of data, and does not appear to retry.

I did the same test with my MD-380 and it seems to try 3 times before giving up.

I’ve looked in the codeplug settings for the GD-77 and nothing I did seemed to make it try more than once to setup the call, and adjusting the preamble time didn’t make any difference at all to the bust of data that the GD-77 sends when it attempts to connect.

The overall effect of this, is that currently it’s not going to be possible to reliably get the GD-77 to connect to the duplex hotspot, if it has other modes also enabled.

I think even with the MD-380 which has 3 attempts to setup the call, its possible that the duplex hotspot may not be listening for DMR signals when the MD-380 does its 3 transmissions.

So Duplex operation of the hotspot should only be enabled if the hotspot is operating in a single mode.

Whilst experimenting with multiple modes enabled on my duplex hotspot, uncovered a minor configuration issue which seems to apply to the default codeplug supplied by Radioddity.

When multiple modes are enabled (in Pi-Star), and the hotspot cycles though each mode, listening for one mode at a time, I found that the GD-77 would rarely connect to the hotspot.

Listening to the transmitted signal, on a FM receiver, I noticed that the GD-77 only made one attempt to connect to the hotspot, despite the GD-77 not giving the warning beep, for well over 1 second.

I discussed the problem with Colin G4EML, and he advised me that the setting which controls this in the CPS is on the Signalling System screen (aka Signalling Basic)  and is called “Tx Wakeup Message Limit”

In my codeplug this value was set to zero (0), despite the minimum allowable value being 1.

A bug in the CPS (which I will fix in my version… Soon…), allows this value to be set to between 0 and 4 rather than 1 and 4.

In practice the firmware treats any value outside the rage of 1 to 4 as a value 1. So there will always be at least 1 “Tx Wakeup Message”, because if it didn’t do this, then values of zero, would prevent the GD-77 from connecting to any repeaters.

The DMR specification recommends 2 retries; which means on the GD-77 that the “Tx Wakeup Message Limit” value should be set to 3.

I think perhaps I should change the name of this menu to be “Tx Wakeup Message Retries” and subtract 1 from the value, as this would be a more sensible way of displaying the data, since its not possible to have zero Wakeup messages

I’m not too sure why my codeplug has zero for this value, because the default codeplug for both the official and my Community CPS have this set to 1.

I presume the value must somehow have become corrupt, when reading back from one of my GD-77.

Since the recommended value in the DMR specification is 3 tries in total, I will change the default codeplug in my CPS to this value.

Just for completeness…

I investigated how the Tx Wakeup Message Limit is stored in the codeplug, and its stored in 3 binary bits as part of one of the “flag”s in the Signalling data block

Its rather strange that Radioddity used 3 binary bits for this, since the value never needs to be zero and the recommend value for retries is 2. Hence even assuming this value is the Message count (Limit) and not retries, the recommended value would only be 3, and if this was used to store retries instead of tries, then the values of 0 to 3 (retries) would be adequate.

When I tried setting higher values (since 3 binary bits can store the values 0 to 7), the firmware seems to check this value, and always goes back to 1 (one) try for any values above 4.
Since this was for values of 5,6 and 7, this means that the firmware is not simply reading the lower 2 bits as a value of 7 should be the same as a value of 3 (ignoring the upper binary bit). Hence the firmware must be reading all 3 binary bits, but checking for values outside of the range 1 to 4, and defaulting to a value of 1 in that case.

A few weeks ago I posted about a few problems I encountered using the Duplex MMDVM hotspot, one of which being, what appeared to be a 60 second timeout.

Following this discovery I contacted Andy CA6JAU who writes the MMDVM_HS firmware, and he was able to reproduce similar problems on his duplex hotspots, but with a timeout which was consistently over 60 secs.

Andy fairly quickly tracked down the problem, and let me know that …

The root of the problem is clock bit rate drift between radio and HS. Because this depends on TCXO small differences (radio and HS), I modified a little the code to minimize this effect. At least here works for all my duplex boards.

Andy released version 1.4.7 to resolve this issue, but he has indicated that this is not a perfect solution.
It just increases the time before the transmitting rig (e.g. GD-77) will disconnect, because ultimately the reason for the timeout is that the TX chip (ADF7021) on the duplex hotspot, does not have its clock signal locked to the incoming signal (e.g. from my GD-77) and over a period of time, either the data buffer in the hotspot under-runs’ (empties) , or over-runs (overflows).

I know some people including Steve K2GOG are investigating using a clock clock rate generator chip, as the clock source for both the Rx and Tx ADF7021, as the clock frequency could be adjusted by the firmware. However I’m not sure if the cheap clock rate generators, like the Silicon Labs Si5351, have too much jitter to be be usable.
If I hear from Steve that he’s got this working, I have a couple of Si5351 breakout boards, so I could attempt to modify one of my duplex hotspots, and I will write a post about it.

In the mean time,… I tested 1.4.7 and my timeout is now 4 minutes.
I’m not sure if this timeout is being caused by the Brandmeister network, server or whether my 60 secs timeout has been multiplied by 4 to now be 4 minutes.

But I think this is an acceptable timeout as most repeaters enforce a 3 minute timeout. So to all intends and purses this bug has been fixed.

Just a quick post in case anyone’s had a similar issue and perhaps can help me with this problem….

I’ve noticed that my GD-77 no longer beeps when it times out.

I have the TOT set to 180, with rekey after 0 seconds; and after 180 seconds the GD-77 stops transmitting and I can see the LED on the top turn from Red to Green, but I don’t get any audible indication that this has happened.

I’ve looked though the CPS settings and I can’t see anything which specifically controls this. I can set the Call Exit tone, and I think this will beep every time I release the PTT, but this is not the same as the Timeout beep.

I initially suspected, I have read back the codeplug from one GD-77 to write it onto another GD-77 and somehow the readback process has corrupted the codeplug data somehow, but in a way that’s not visible my any option in the CPS.

But I built a new codeplug with just one channel for my hotspot on TG9, and this isnt giving the timeout beep either

I’ve tied this simple codeplug on a GD-77 that’s running firmware 3.0.6 as well as one that’s running firmware 3.1.6 and I get the same problem on both radios, so I’m beginning to wonder if this issue only effects hotspots.

I guess I’ll need to setup minimal codeplugs to access a local repeater and try that, and perhaps I can figure out why at least 2 of the GD-77 I have at the moment, no longer beep on timeout

Just a quick followup post about the incorrect (default) Tx retries setting on the Radioddity GD-77.

Several people have let me know that the Tx Sync Wakeup TOT [ms]  value also needs to be increased to 325

Thanks to Jason VK7ZJA for this original information and also to Rob W1AEX and others who posted screengrabs from Jason’s post to FB.

Over the last few weeks I’ve been experimenting with the duplex MMDVM board, and it continues to have some problems which I thought I should share the details of…

1. Not all of my radios connect reliably when the board is in duplex mode.The GD-77 seem to have the least issues connecting.

   The MD-380 will only connect if I change the DMRTxLevel to a higher value than is normal (somewhere between 53 and 57 seems to work).
   AFIK this setting changes the FM deviation of the 4FSH being produced by the ADF7021 transceiver chips on the board.

   I’ve had reports where MD-380’s would not connect at all, but I’ve also spoken to people who have a MD-380 and didn’t need to change the Tx Deviation.

   Also… when I change this value, the GD-77 has problem connecting.

   Even when my MD-380 manages to connect, the board seems to occasionally confuse which TimeSlot the MD-380 is transmitting on, with the result that no audio is received by anyone who is listening.

   I discussed this with Andy CA6JAU who writes the firmware, and he said there are general problems with the MD-380 connecting even to the simplex versions (e.g. Zumspot and JumboSpot), which are normally resolved my adjusting the DRMTxLevel.

   The other possible cause of the problem is time delay though the board, between when the MD-380 sending the connect (wake-up) message and when the MD-380 receives the response. However at the moment its unclear quite what is causing this issue, and unfortunately I don’t think Andy has time to investigate.

2. When leaving a pause (break) before pressing the PTT in response to the last incoming over, the GD-77 seems to occasionally not connect – but does not give any notification that its not connected.It appears that if I press the PTT within one or perhaps two seconds, that the GD-77 seems to connect on most occasions, but anecdotally leaving a pause / break, seems to increase the chances that a connection fails.

   Whats strange is that if the GD-77 can’t connect, it normally beeps and stops transmitting after around 1 second. But in this case it continues to transmit, and the Pi-Star dashboard indicates that the hotspot is not receiving the transmission.

   This could be an issue with the way Pi-Star displays the status, however I think that the duplex hotspot board is not signalling to MMDVM Host that it has an incoming signal, but is still sending data back to the GD-77 hence it thinks that everything is working fine.

   I need to do more tests to attempt to confirm whether this problem is exacerbated by leaving a pause, or whether it happens at random, and to also determine where in the hierarchy the problem lies. i.e MMDVM_HS firmware or perhaps MMDVMHost or even DMR Gateway.
   My guess would be an issue on the board / firmware.

3. Operating in duplex mode, the board is unable to support DMR and other modes at the same time (i.e where board scans for each mode for a short time.)

   I’ve posted about this before, but basically the ADF7021 chip on the MMDVM hotspot, has to be setup to receive different types of modulation when listening for DMR  to when listening for D-Star or YSF etc. Hence board listens for each type of modulation for a short time, in its scan loop.

   The problem is that for duplex DMR operation, where the transmit and receive frequencies are different, the transceiver e.g. GD-77 sends a connection (wakeup) data packet to the “repeater” and expects a fairly instant response.

   However if the duplex hotspot happens to be listening for D-Star (or YSF or P25 etc) when the transceiver sends this connection data, the duplex hotspot will not send back a response to the transceiver, and hence it won’t connect.

   The transceiver should make multiple (probably 3) connect attempts, with a small gap between each ( I think around 250 mS between attempt), but its possible that the duplex hotspot would not be listening for a DMR signal during any of the connection requests.

   The firmware already listens for DMR signals for something like 10 times longer than it listens for the other modes, but this is not long enough to guarantee it listening at the correct time.

   There may be a partial workaround for this, to change the duplex firmware, to listen for DMR signals for at least the as long as the time required to hear two connection requests, and to not listen for other modes, for longer than the gap between connection requests.
   This would probably mean that the scan loop would need to be changed from (for example)

   DMR
   D-STAR
   YSF
   DMR
   D-STAR
   YSF
   etc

   To

   DMR
   D-STAR
   DMR
   YSF
   DMR
   D-STAR
   DMR
   YSF
   etc

   However I don’t know if this would impact on the detection of D-STAR or YSF or the other modes

   It could also potentially result in the loss of the first second or two of audio for other modes.

4. Even with the fix that Andy wrote; my board still has a timeout of around 4 minutes.
   Its possible that some boards have a worse timeout, as the value seems related to the difference in clock frequency in the transmitter e.g. GD-77 and the hotspot.

   My understanding of this problem is that there is no way to synchronize the data packets arriving from the transceiver (e.g. GD-77) and the data being sent back to from the hotspot. This is because the ADF7021 does not have a “recovered” clock output.

   I think there may be some hardware and firmware changes which may be able to fix this in the long term, but there is no simple fix for this without modifying the hardware.

I suspect there may be other problems that I am not aware of, so please feel free to comment if you have another problem with these boards.

My overall view of these boards is still that they are generally good value, as they cost less than $10 more than the Jumbospot. But it is very new technology and you may potentially have to run it in Simplex mode, either permanently or until specific problems are fixed.

Over the last month, I’ve started to notice the limitation in the GD-77’s callsign lookup, based only on using the Digital Contacts.

To improve things a bit, I added a new screen into the Community CPS a few weeks ago, to allow the DMR ID database to be updated, using the same data download, from Ham-digital.org.

As far as I’m aware, this is working OK, but has a drawback, because of a bug in the GD-77 firmware, which causes the data (i.e callsign)  to be retrieved from the DMR ID data, even if the same ID exists in the Digital Contacts

So to resolve this problem, I’m probably going to replace the “Download contacts” screen with a modified version of the DMR ID screen.

This will allow a list of DMR ID’s, callsigns, names and ‘last heard’ (inactivity count – in days), to be downloaded like it currently is. But there will be options to update the Digital contacts with this data first, and to upload the remaining ID’s into the DMR ID system in the GD-77

This may require 2 separate uploads, or I may be able to do in one upload (using 2 uploads will be my initial approach as its safer to use the existing codeplug update system to upload the contacts to the GD-77) , however in the long term, it should be possible to upload the Digital Contacts and the DMR ID in what appears to be the same upload (even though it will be uploading to 2 separate blocks of Flash memory in the GD-77)

Another change in the pipeline, is to improve the Channels export and import, so that it exports (and imports) all settings, not just a subset of the settings. I have this working already, but it needs more testing before its ready to be released.

I’m also going to change the import feature, so that it does not delete all existing channels before importing, but will instead check each channel name in the CSV file to see if the same channel already exists in the codeplug, and if so, it will simply update that channel.

New channels (ones not matching the name of an existing channel in the codeplug), will be added.

This will allow channels to be added a lot more easily, but will only fully work if the channels use Rx Group lists and Digital Contacts and Scan lists, that are already in the codeplug.

If these new channels reference anything thats not already in the codeplug, the values e.g. of Contact, will be set to “None” and these will need to be changed manually after the new Contact (Talk Group) etc has been added.

In the longer term, I’m considering getting the Channels export to save the associated Digital Contact, Rx Group and also Scan list data, in the same CSV file.

I’m probably going to add a new column at the start of every line, which indicates what that line in the CSV file holds.

e.g. Channel, Contact,RxGroup, Zone or Scan list

Then when the Channels import system reads the CSV file, it will first process Contacts and add and update as necessary. Then process Rx Groups (as they reference the Contacts), then process Scan lists, before finally importing any Channel data , followed by any Zone data (because Zones use Channels)

I’ll also need to decide which screens export this data. Currently AFIK, only the Channels and Contacts screens have the ability to export and import. All the other sections, do not currently have the same sort of listing screen (Data Grid View) which the Channels and Contacts have, and I’d probably need to add something similar, to each of these sections before I can add the export/import features to them

This is especially true of the Rx Group lists, as they have no overall settings screen at all.

However, I will be doing this one step at a time, and I’m not likely to release anything until I have the Channels export/import system working well

I’m keen to have user feedback, so if anyone can think of a flaw in my plan, or has another approach, I’d be interested to hear, but I can’t guarantee I’ll have time to implement any of this, in the immediate future.

I’ve been giving a lot of thought to the best way to handle exporting and importing of channels into the GD-77 over the last few days, and I think I’ve finally come up with a reasonable idea to make it easier to export and import all the information that will allow channels to be exported and then imported with the minimum of hassle

Note. The changes I describe below have not been released yet as I’m still testing them…

• I’ve changed the Channels export to export all data associated with each channel (not just the limited subset which the CPS currently exports). This means that channels that are imported are not missing vital data needed for DMR operation.
• I’ve modified the Import feature so that it does not clear (delete) all channels before importing.
  My new version, checks each channel as its imported, and if it matches an existing channel name, the existing channel is updated with the revised information from the CSV data.
• I’ve add (actually re-enabled a hidden feature), that allows groups of channels to be deleted.
• I’m going to remove the “Clear” button, as this is basically superseded by the “Delete Selected” button, as multiple rows can be deleted by clicking on the first row and shift clicking on the last row.

During the import, its currently possible to for a channel to use a Contact name, which is not in the list of digital contacts. This currently causes the “Contact” to be set to “None”. The same applies to Rx Groups and Scan lists.

In these cases, currently you would need to manually change these channels to select the correct Contact, Rx Group and / or Scan list.

However, I had a brainwave this morning, and I’ve realised that…

Ideal 1 (Contact data and Rx Group lists)

If I include the Contact Type and Contact Number, as part of the channel information, that I can create (add) new contacts (TGs or PCs), when a channel is imported.

Also if the RX Group referenced by a channel does not exist, I can use the Contact data to either find a Rx Group with that Contact in it, or possibly make a new Rx Group.

There is a slight problem with this method, because if I create a new Rx Group with the Contact assigned to the channel that’s being imported.
When the import function encounters the same Rx Group name again, it would presume that it was a pre-existing fully populated Rx Group list and not one that was created by the importer.

Probably the best way to overcome this issue is to check that the Rx Group specified for a channel, contains the Contact (TG) used by that Channel.
And if the Contact is not in the Rx Group, then try to add it to the Group.

This is not foolproof, because an Rx Group can only contain 32 Contacts, and a mall-formed CSV (created manually) could have omitted to correctly set the Rx Group.

Hence some error checking will need to be added to the import system to handle this, and perhaps abort the import if that occurs.

This will slow down the import process slightly, but I suspect the difference in speed will be barely noticeable on most modern PC’s

Idea 2 (Scan lists)

I don’t personally use  Scan Lists, and I’m not sure why the Scan list needs to be specified in the Channel data at all.
Perhaps someone can explain why this is necessary….

However, if the importer encounters a Scan list name that is not an existing Scan list, then a new list could be created.

What I don’t know is whether the Scan list should have that channel in it, because at the moment the CPS does not seem to enforce this.

Idea 3 Zones

If the channel is in at least one Zone, I can include the Zone name in the data (CSV line) for that channel when its exported.

Then when importing each channel, I can check of a Zone exists with that name and if it does not, the importer can create the Zone and add the channel to it.

Like Rx Groups, if the Zone already exists, I’ll need to check that the Channel is in the Zone, and if not, I’ll need to add it.

I think if I make the changes described above, it should be possible to do almost a complete import, by just having a spreadsheet containing this augmented channel data.

It would not be able to handle instances when the same channel was in multiple zones or multiple scan lists, but I intend working on having separate systems to export and import both Zones and Scan lists (and probably Rx Groups, just for completeness).

And if all else fails, Colin G4EML has a very good Codeplug file < —- > multiple CSV system, which can be used instead.

Following on from my last post about improving the GD-77 CPS, channels export / import improvements I have been working on.

I’ve not got a beta version which I think  may work OK.

So if anyone is wants to give it a try, the installer can be downloaded from my google drive  using this link

https://drive.google.com/open?id=1VipL-KKx7FxkLf0hyM8VsFavxKU05h9z

Please make sure you backup your current codeplug file before experimenting with this Beta version.

The functionality improvements are basically the same as I described in my last post.

The Channels screen, export feature now exports all the data associated with a channel, and additionally includes the digital Contact ID and digital Contact Type (Group or Private call), as well as the Rx Group name and the first Zone that contains the channel in question.

The export feature only exports the channels (rows) that you select on this screen, which allows a subset of the channels to be exported separately, e.g. you could select you analogue 70cm channels or analogue 2m channels, or just some digital channels etc.

When importing, the existing channels are not cleared first, which allows new channels to be appended.

If a channel with the same name that is being imported, already exists, the existing channel is updated.

If a channel that is being imported uses a digital Contact that is not in the Digital Contacts list, the contact will be added

If a channel that is being imported uses an Rx Group that does not exist, the Rx Group will be created and the digital Contact assigned to the channel will be added to the Rx Group.

If the Rx Group already exists, but the Contact assigned to the Channel is not in that Rx Group, it will be added to the Rx Group

If the Zone which uses the channel, does not exist, it will be created and the channel will be added to that Zone.

If the Zone already exists but the channel is not already in that Zone, the channel will be added to the Zone.

One thing to be aware of with Zones, is that if the channel was in more than one Zone in the codeplug from which it was exported, only the first Zone name in the list that contain the channel, will be included in the channel data.

Hence when importing, only one Zone will be created

Currently the Zones can’t be exported in their own right as the CPS is lacking several screens, e.g. there is no Rx Group lists screen, or Zones list screen or Scan Lists screen.

When I get time I will create these screens, but its taken me quite a while to get the Beta of the “enhanced” Channels  export/import system working, and I have other higher priority things that I need to do in the CPS, like combining the DMR ID and Contacts import, to make best use of the lmiited number of Digital Contacts which have 16 characters per ID, and hence can display the Callsign and Name, unlike the DMR ID system, which only allows 8 characters per ID, hence there is only room to display the Callsign

I’ve done some testing myself and have not had any major problems, but since I’m generally just clearing my codeplug and importing sections of my previous codeplug, its probably not the best of possible tests.

So I’m keen to get feedback from other people

BTW. One niggle I already came across is that I its impossible to remove all existing Zones or all existing Contacts or Rx Groups, so you can end up with Zone which is empty and unused at the start of the Zone list.

One way to get around this is to rename the Zone to the same name as a Zone in the data you are about to import – but I agree this is not ideal and I’ll need to find a better solution.

<rant mode=”on”>

However the main problem is the underlying data structure internally in the CPS.

IMHO the internal data in the CPS has a fundamental design problem. All the data storage is almost a direct copy of the binary structure, which is sent to the GD-77. i.e its in a format thats easily readable by the firmware in the GD-77 but is a pain to manipulate in the CPS.

I think the data structure internally to the CPS should have probably been in a form of a mini database with relational links between the different sections. Or perhaps using C# objects which referenced each other.

Rather than the arrays of objects which it actually uses.

This would make the CPS more flexible, and would just require a function to generate the binary data from the CPS object data and vice versa. But this was not the way the programmers at Radioddity chose to implement things, hence the lack of functionality in the CPS

</rant>

Doing some testing of my enhanced Channels export/import for the GD-77 Community CPS, I realised there was a problem if the same TG Id already existed in the codeplug, but was assigned a different name to the data in the CSV file.

This resulted in 2 contacts with the same ID being created, which although it seems to work, in that the channels are usable… I found that if either of the duplicate number contacts was opened, the CPS displayed a warning message and change the Id to the next available free Id number.

To resolve this problem, I’ve created a new Beta version (Beta 2) which can be downloaded from here

https://drive.google.com/open?id=1VipL-KKx7FxkLf0hyM8VsFavxKU05h9z

Which checks the Call Id number and confirms whether an existing contact with that Id exists, rather than checking for the contact Name.

If a contact with the same ID exists, then the channel uses the existing contact (and it will display with the existing contact Name)

If the ID does not exist a new contact will be created with the name in the CSV  (for the channel being imported).

If you already downloaded the previous Beta, please download this updated version and install it

Note. I updated the link in my previous post and removed the original file from my Google drive.

While working on the enhanced Channels export and Import feature I noticed that its not possible manually delete the first Channel, or the first Zone of the first Rx Group etc.

But the Channels import feature used to remove all Channels before importing.

Doing some further testing, I found that it appears to be possible to delete all Zones , and Rx Groups etc, prior to importing, with no apparent problems.

Not being able to delete the first Zone or Rx Group etc and not having the ability to re-order the Rx Groups, means you get stuck with a Rx Group you may not want.

So I’ve now decided to investigate why the CPS does not allow the deletion of the first Channel etc.

I modified the CPS to delete all Zones and Rx Groups and even all Channels and uploaded / wrote the codeplug to my GD-77 and it doesn’t seem to cause any serious problems.

The GD-77 just displays “Ch Empty” for all Zones if all channels are deleted, and even if all the Zones are deleted, the GD-77 still seems to display the Zone name of the first zone it had in memory prior to the Zones being removed.

When I tried to transmit on a Channel that was displaying “Ch Empty”, the GD-77 just displays a message , something like “Freq Error” and doesn’t transmit.

So I can’t see any serious interference problems being caused by having empty channels.

Actually empty channels in a Zone are possible even without modifying the CPS, anyone can try this, simply by making a new Zone and not adding any Channels to it, then upload to the GD-77 can select that Zone.

Anyway, my current thoughts are that I should try allowing the deletion of the first Channel, Rx Group or Zone etc, but I will need to do some more testing, to see if these have worse side effects than deleting all the Zones etc.

I’ll hopefully produce a Beta 3 version, in the next day or two, which allows these deletions and put that on my Google drive, so that perhaps other people can do some experiments and let me know whether there are any problems.

And I’ll do another post with that version…

Following on from my previous post, I’ve made a number of changes to this experimental version of the CPS

https://drive.google.com/open?id=1BhkhMTMwlX2_rUTbAEJNU2ic3q93tic-

In the “TreeView” I’ve removed the checks that prevented the first Channel, or Contact or Rx Group or Zone etc, from being deleted.

So its now possible to delete everything except VFO’s (as the GD-77 can only have 2 VFO’s and you cant add or remove VFO’s)

I initially had some problems with zones getting duplicated when I removed them all, but I’ve fixed that in the version I’ve put on my google drive (see link above)

What you still can’t do is delete the last channel (or Scan list etc etc) that you have open for editing.

e.g. if you double click on the first channel, the delete button on the Channel screen is still disabled.

In fact, it looks like there is an existing bug on the Channel screen, as its not possible to delete either of the last 2 channels from the Channel screen.

I’ve modified the Channel (and other screens), so that if you have a channel open for editing and delete it via the TreeView, I close the Channel screen.

(The same applies for all screens except the Emergency System screen, which I forgot to modify to handle its data being deleted while its open)

I’ve done a few tests, including deleting everything (except the Emergency System – which I forgot to delete), and then imported part of my codeplug, and the radio seems to work fine.

I’ve tried uploading a virtually empty codeplug and the radio didnt seem to crash, but it didnt have valid frequencies to receive or transmit on, so it gave an error when I tried to transmit.

It would be great if anyone reading this blog post could give this latest (highly experimental version a try), and let me know if they find any side effects of being able to remove most things

e-Ink, also known as e-Paper displays have become a lot more affordable in the last year, with several Chinese companies selling modules with or without a built in mircocontroller, so I finally decided to buy a few to test.

One of the more interesting display + micro-controller modules is the “TTGO T5” module, which features a ESP32 WiFi processor, and a 2.9 inch e-Ink display, 3 buttons (4 if you include the “reset” button), a micro SD card socket, and a small speaker / buzzer, and CP2104 USB to Serial IC to allow the ESP32 to be programmed, as well as debug messages to be displayed

From the start, I found there is a distinct lack of information about this unit, specifically how the display is connected to the ESP32 and also which pin the speaker is connected to.

My impression is that these modules are not specifically design for the maker / hobbyist market, but are probably designed to be used in some sort of domestic electronics, like a heating controller.

I found this information, in a listing on Amazon

But this still leaves a lot of unknowns.

I still don’t know, the meaning of the header pins, “P” and “5”. Both of these appear to have 1.7V on them, but knowing the voltage doesn’t help much

There are 4 blue SMD LEDs on the back of the module, as well as a red LED.

The red LED is probably an indication of power, because it lights up as soon as power is applied.

The blue LED’s seem to be connected to an IC marked as a IP5306, which appears to be a 2.1A multi-function power management device with integrated boost converter, and  lithium battery charge management and other features.

Next to the IP5306 is a small connector, labelled + and -, and the + pin is connected to the header pin labelled as VBAT, so I’m fairly certain, that’s how the battery would normally be connected when the module is used commercially

So the module has definitely been designed to run from a lithium ion battery, as well as being charged via the USB connector, however I’ve yet to connect a LiPo battery to the board.

In addition to the IP5306, there is another power controller IC, the EA3036

http://www.everanalog.com/Product/ProductEA3036DetailInfo.aspx

My guess is that potentially this IC is being used to generate the voltages needed for the eInk display, but I have not confirmed this yet.

Another interesting IC on the board is a NS4148, http://www.chipsourcetek.com/Uploads/file/20151207193630_0605.pdf which is a “3W mono – Class D audio amplifier”, which explains why the small speaker that comes attached, via a flying lead, to the module, can be made to beep surprisingly loudly.

I suspect that the module could drive a larger speaker and potentially could be used to play either music or possibly voice prompts, if software could be found for the ESP32 to support this.

By trial and error, I found that the speaker could be made to beep, if I enabled PWM onto pin GPIO 25 of the ESP32.

In my testing I found that applying PWM to pin GPIO 26 caused a small amount of audio to be produced on the speaker, which made more sense when I found that the NS4148 is an audio amplifier.

I suspect that the tracks of the PCB for ESP32 pins 25 and 26 are routed on the PCB next to each other, for around 5 cm, which causes enough capacitive coupling for the modulation on pin 26 to bleed through to pin 25.

I supposed I should not have been surprised that the speaker is connected to GPIO 25, because this pin is also DAC 0, as this allows low quality audio to be played through the speaker.

To test this, I found an Arduino sound library (XT_DAC_Audio) for ESP32 on this website http://www.xtronical.com/the-dacaudio-library-download-and-installation/ which worked straight out of the box.

The WAV playback example included in the library was a low quality audio sample, so I made my own loop using Audacity from Curtis Mayfield’s “Move on up” (youtube will probably have a clip of that), and this sounded a bit better than the example audio, even though I down sampled to 22kHz and the file has to be 8 bit wav.

However the sound was still very “tinny” and it sounded like the speaker was being over-driven.

Reducing the wav file volume to 50% gave a small improvement. I also tried connecting the speaker pins to a small good quality home HiFi speaker, (“Mini monitor”), which is a 6 Ohm speaker with both woofer and tweeter. This produced a very loud sound, probably the full 3W that the amplifier chip is capable of delivering, and was an improvement in audio quality. But there were still a lot of high frequency noise components.

I don’t know whether the noise components are caused by the DAC or the audio playback library, or the amplifier chip being over-driven. Needless to say, I don’t think this module was every intended to play anything other than perhaps basic tones or simple tunes, and it works well for what its designed to do.

The tiny speaker that came with the module has a self adhesive coating on one side, protected by a removable strip, and seems to be intended to be stuck to the inside of the case of whatever device it was intended to be used for.

I think the design of the case will also play a big part in the sound of the audio, because simply pressing the speaker down onto my desk, seemed to improve the audio quality.

On thing I would like to try out is possibly a “Mod” file player. (I found this on github which may work)

https://github.com/earlephilhower/ESP8266Audio

But I’ve not had time to try this yet.

BTW.

I didn’t notice any bleed from pin 24, which is probably because pin 24 does not appear to be connected to any of the headers or unpopulated through holes on the PCB

Apart from the ESP32, the only other IC on the back of the PCB is a Winbond 25Q32 (32Meg Bit flash memory – 4M byte), which is connected directly to the ESP32. I think the ESP32 supports 8Mb of external flash, but 4M bytes seems to be an average size on ESP32 modules at the moment.

The connections to the eInk display do not seem to be listed anywhere, but I found that using an Arduino eInk library from https://github.com/ZinggJM/GxEPD , that the eInk worked without me having to change any of the pin designations in the example code.

Hence the pins used for the eInk display appear to be

CS/SS GPIO 5

DC GPIO17

RST GPIO16

BUSY GPIO 4

plus the default ESP32 SPI data and clock pins

There are 5 through holes which are not populated, and these are labelled as being connected to GND, 3.3V, IO21, IO22 and 5V

I’m not sure what this would be used for.

I first guess was that its a programming port but I don’t know enough about IO21 and IO21 to determine whether these can be used to functions other than GPIO.

On the front side of the PCB is the 2.9inch display. Its resolution is a bit strange as its 296 pixels in one dimension and 128 in the other.

The display is monochrome only. Just black and white, and not a third colour, (some eInk displays are Black, White and Red, or Black White and Yellow, but this one is only Back and White)

It is pure monochrome, not grey scale, so you’ll notice I had to pre-process my photo into a 1 bit deep diffusion pattern image to simulate grey scales, but you don’t need to look that closely to see the individual dots.

The 2.9 inch display supports partial updates, so that a rectangle of the display can be cleared to white, rather than needing to clear the whole display before changes can be made, however I found that partial updates can leave undesired traces of the previous values of the pixels, so its generally better to clear the whole screen before each update.

Also on the front of the board, are 4 buttons, 3 of these are “user” buttons, in that they don’t have a predefined function, but the forth button is connected to reset, and can’t be used for anything else.

The buttons are all pulled high and go low when pressed.

Overall, at around $30 for the whole module, including the display, and the speaker etc, I think its a reasonable price, and the module looks like it could be useful for a wide variety of projects, both power from USB and also battery operated.

In the last few days I’ve been attempting to resolve a major design fault on the TTGo T5 eInk display board, where the battery management chip (IP5306) was completely turning off the power to the ESP32, and the other chips, when I put the ESP32 into deep sleep mode.

The problem is a design fault, and is primarily because the battery management chip (IP5306) is designed for “power bank” devices, where a LiPo cell is used to power a 5V USB device, rather than powering a microcontoller or any other 3.3V devices.

The IP5306 only has a datasheet written in Chinese, but I noticed that it had an option to attach a button to pin 5, and grounding this pin, via a resistor, caused the chip to wake up and put 5V on its pin 8.
Also momentarily pressing the button, while the chip was awake, cause it to stay awake even when there ESP32 was in deep sleep and and consuming hardly any current.

So my first idea was to make the the ESP32 “press the button” by connecting one of its GPIO pins to the button pin (5) via a 1k resistor, then make the ESP32 wake up from deep sleep to metaphorically press the button, every 30 seconds, before immediately returning to deep sleep.

This was never going to be a perfect solution, as the IP5306 (battery manager) seemed to need a button press pulse of at least 100 milliseconds, hence the ESP32 would need to be consuming its normal current for 0.1/30  of the time. But this would only be 0.3% of the total time, so I thought if this method worked, it would be adequate.

Unfortunately, although initially this strategy appeared to work OK, I found that if I left the board running from a battery overnight; when I checked in the morning, the IP5306 had turned off.

I think that the IP5306 probably has a maximum operation time, or perhaps a maximum count of the number of button presses which it allows before turning of when there is virtually no load.

But whatever the reason, it became clear that the IP5306 is totally unsuitable for the application to which its been put, and I took the radical decision to remove the chip from the PCB completely and use an external battery charger / protection module instead.

I have a hot air reflow tool, but because I didn’t want to damage any components near the IP5306, I decided to cut its legs, to remove it. However I found that even after cutting all 8 visible pins the chip seemed to be stuck to the board.

What I didn’t realise was that its a 9 pin package with a large Ground terminal on the base of the chip, which probably also acts as a heat sink. Luckily they had not used that much solder paste under the chip and I it came away without too much force and the board was not damaged.

Once the chip had been removed, I was able to solder a wire to the pad for pin 1, which receives 5V when the board is connected to USB (or I presumed powered via the 5v pin on the header), and a wire to pin 8, which was the output (5V which I presume feeds into the EA3036 multi output buck converter), and a third wire to the ground pad in the middle of the IP5306 footprint.

I already have a stock of TP4055 based battery charger modules with built in battery protection. So I soldered the module to these 3 wires, and connected the same 2000mAH LiPo cell to the new battery charger module.

Once everything was connected, I was surprised to find that the battery charger module was only outputting 1V, even though the battery was almost fully charged and measured as 4.15V, and initially I thought perhaps the charger module was faulty; however I found that if I supplied power via USB, not only did the whole TTGO board start working, but when I removed the USB power that it continued to be powered via the LiPo battery.

So it appears that these battery charger / undervoltage protection modules need to be initially primed with 5V on their input before the undervoltage protection is removed.

Running from battery power, of around 4.1V, the TTGO 5T board seemed to work fine, and checking the spec of the EA3036, in theory it will operate with an input voltage as low as 2.7V, which is less than the minimum operating voltage on the LiPo cell, so I think the TTGO board will work fine from battery, however I will leave it running a Wifi server (drawing around 100mA), until the battery voltage gets close to its minimum value, to confirm my supposition.

However before leaving the battery drain program running, I also tested the current being drawn from the battery when the ESP32 was put into deep sleep mode.

Unsurprisingly I found that the TTGO board as a whole was taking around 7mA, but I was not surprised because the red “power” LED was still illuminated and I thought perhaps that accounted for the majority of the current.

But I was wrong…

I removed the LED and found virtually no difference in the current being drawn from the battery. So the next step was to check whether the current was actually being drawn by the TTGO board or by the new battery charger / protection board.

So after a small amount of rewiring and my multi-meter connected between the new battery charger module and the TTGO board, I measured virtually the same current.

By now I wasn’t particularly surprised by this, because the NS4148 class D audio amplifier chip has a typical standby current of 3.5mA, and could potentially be taking more, plus I am not sure how much current will be taken by the EA3036 buck converter even when it has virtually no load on one of its outputs.

So the next set of tests I need to perform are to around the NS4138, and I’ll probably have to find the pullup resistor for its “CTRL” pin, which needs to be pulled low in order for the NS4148 to be put into its low power standby mode.

However I think if putting the NS4148 into standby does not radically reduce the power that is consumed, I will not have much scope to improve things, as the circuit may also include multiple wasteful pullup/ pulldown combinations and these could be hard to track down, and the EA3036 would need to be replaced with something which had very low quiescent current properties, and I’m not quite sure what devices would fit the bill.

BTW. It looks like disabling the outputs on the EA3036 that drive the NS4148 is not practical as the “enable” pins are connected together and only have a short length of track on the PCB before they go to a via, and it will be hard to track down where the via goes.

Also using a 2000mA battery, a 5mA load would in theory last around 16 days, and this is probably adequate for any use I can think of for the whole module.

Anyway, I’ll post another followup article when I have had chance to do a discharge test on the battery and also experimented with the CTRL pin on the audio amplifier.

Update. 11th Oct 2018

I’ve managed to get the current drain down to 1.5mA but I don’t think its practical to get it any power.

I removed the pullup resistor on the NS4148 audio amplifier CTRL (Pin 1) and soldered a 10k resistor to ground instead.

I then connected the IO19 header pin to Pin1 on the NS4148.

This keeps the NS4148 in low power mode, until I drive IO19 high. i.e before I can play any audio, I have to do this, and afterwards set IO19 as high impedance (aka input)

I’ve had a look at the EA3036 multi output buck converter, to see if I could use its ENable pins to shut down part of the chip that was not driving the ESP32, but this would be hard to do, because all the enables seem to be directly connected together and share the same (10k) pullup resistor. So it would take some extremely delicate surgery on the board to cut the track(s) right next to the chip and control the outputs separately.

And I’m not entirely sure whether that would actually help reduce the current, as 2/3 of the EA3036 would still be running

So without a schematic for this board, its going to be very difficult to know what else could be taking any current.

Consequentially, I think I’ll need to live with 1.5mA when the ESP32 is in deep sleep.

PS. I’m still doing battery voltage testing, but since I have a 2000mAH battery attached, its taking ages to flatten it just using the current drain from the ESP32 with its Wifi turned on.

So I’ll either need to leave it on for a few days, or find a way to drain the battery a lot faster.

I received a heads-up from Torben Hoerup this morning to let me know that Radioddity had released a firmware update for the GD-77.

The update comes in the usual zip package and also contains the CPS, ActiveClient and also a new folder called “Read Me First”

In the “Read Me First” folder, are some new documents, which Radioddity seem to have cobbled together from various sources, including a FAQ written by Jason VK7ZJA – though I don’t know if Jason realises its now been distributed by Radioddity

The CPS seems to be unchanged from the previous versions, and the folder containing the CPS is called “Program software V3.1.1 (Same as last version)”  which I presume reinforces that there has been no change to the CPS.

The ActiveClient software also appears to be the same as its modification date is still 2017.

So the only change appears to be the firmware, and the change in the firmware appears to be limited to DFTM

Specifically the update diary file this new section for firmware 3.1.8

Firmware V3.1.8

1: Solve DTMF decoding issue–the other channel number cannot be decoded after the DTMF in Double Standby (Double Single)

2: Add ANI display

I think the DTMF change is self explanatory, however the “Add ANI display” is still a bit of a mystery.

The only references I can find to ANI are for “Automatic Number Identification”, and seems to be related to DTMF, rather than the DMR ID.

I did some tests on DMR an the DMR ID appears to work the same as before, and since ActiveClient has not changed, I think that both of the changes in this firmware release are probably related to DTMF operation and are not aimed at the Amateur Radio market

I’ll probably update both of my GD-77 to this version, as potentially Radioddity have done other bug fixes which they have documented, but as this new version does not include any of the enhancements that the Amateur Radio were hoping for (I checked and there is nothing on the menus to enter a Talk Group   ), I don’t think anyone needs to be in a hurry to update.

Update after 1 day’s use of the new firmware

The firmware seems to be working OK, but they don’t seem to have fixed any other bugs. Both my GD-77 radios seem to forget which channel they were set to when I turn them off, so that when I turn them back on again, they seem to go to a channel which I had to set to a few days ago.

I’ve updated the DMR ID data it seems to display the same as it did before – so now change there.

I’ll post again if I notice any changes at all

Just a quick post about how to setup PiStar and your codeplug to work with the new DMR+IPSC2 server

The new IPSC2 server allows for a wider range of connection options, in that it not only supports access via TalkGroup 9 via a reflector (e.g. Reflector 4800 = DMR+ TG505), but also now supports direct transfer of the TalkGroup being transmitted by the transceiver into the server.

To use the new feature, you will need to change your PiStar settings if you have a Brandmeister / DMR + configuration, using DMR Gateway to only connect to DMR+ISC2 Australia

The trick to get this to work, is also to set some Static Routes in the Options e.g. in my case

TS2_1=505;TS2_2=3803;TS1_1=113;TS1_2=123

This tells the server that you want to route traffic on TS2 TG505, TS2 TG3803 and TS1 TG113 and TS1 TG123 back to your hotspot.

If you don’t add these options, the sever will only route traffic on TG9 back to your hotspot and you will not hear any traffic at all.

Additionally, the codeplug in the transceiver needs to be changed, so that you transmit to the hotspot on your chosen TalkGroups (not just TG8 or TG9), and also these TG’s must be in the Rx Group you assign for the channel.

i.e Basically the hotspot operates in a very similar manor to a real repeater, except in most cases people are running a simplex hotspot, so it can’t both transmit and receive at the same time.

In my case I’m running a duplex hotspot, which will transmit and receive at the same time and work on both TS1 and TS2 independently.

Note. I have not tested whether the normal Jumbospot – simplex hotspots will support both TS1 and TS2 operation so I’d advise testing with just TS2 options first

After using the new GD-77 firmware for a few days, I’ve noticed that there appears to be a new bug associated with the DMR ID / Contact display.

When transmitting to a repeater, after I release the PTT, the incoming ID is shown on the screen, which is my DMR ID – this is normal – but in firmware 3.1.8 the DMR ID does not get removed from the screen after the transmission from the repeater ceases, a few seconds after the PTT is released.

Looking carefully at what happens, it seems that the DMR ID is not always displayed, on either 3.1.8 or previous versions e.g. 3.1.6, when transmitting to a repeater, but it seems that if you transmit for more than a few seconds, then release the PTT, the DMR ID is normally displayed.

In firmware 3.1.6, the DMR ID always seems to be removed when the repeater stops transmitting, (and goes back to showing the channel name), where as in 3.1.8 it always seems to hold on the DMR ID.

The operation of the DMR ID display is slightly intermittent on both 3.1.6 and 3.1.8, but I have not been able to reproduce the bug where the ID is not removed, when I use 3.1.6, however it seems easy to reproduce on 3.1.8

My guess is that this is a side effect of the ANI display system that has been added to display DTMF ID numbers, and is interfering with the DMR ID operation.

Just a quick post, because I’m not entirely sure whats going on….

But I just tried to changed my hotspot frequency, and tried to upload a new codeplug with the revised frequencies in it, and the GD-77 does not seem to have noticed the changes to the frequencies after I uploaded the new codeplug

However when I went back to firmware 3.1.6 and uploaded the new codeplug again, it worked OK.

I’ll need to do some more testing, but currently I’d not advise that people update to firmware 3.1.8 as it appears that there are multiple problems with it.

I may be wrong, but I wonder if the new directives from the FCC about not allowing out of band operations, have something to do with this. Probably not, but I’d not be surprised if this is something they would start doing at a firmware level, to adhere to their FCC validation.

Several months ago, John VK4JWT asked me if I knew of a way to switch his JumbSpot between Brandmeister and DMR Marc using some sort of physical switch.

John was interested in this feature, because he does a lot of mobile operation and it would be much easier to be able to flick a switch on the hotspot, when driving along in he car, than it would be to mess around with different channels and reflector codes.

Unfortunately at the time I had a lot of other projects on the go, and only had time to investigate the theory of how this could be done; however the recent changes to the Australian DMR MARC network , to use IPSC2 and direct talk group access to the Australian MARC network, got me thinking about this problem again, and I have finally come up with a solution, where I have an external 2 position toggle switch connected to my duplex hotspot, where one position tells PiStar to connect to DMR MARC and the other position tells PiStar to connect to Brandmeister.

Note.

Before I go into the details.. Although I have made this modification to my duplex hotspot, I have checked the schematic for the simplex hotspot aka JumboSpot and as far as I can see, it should work fine on the simplex hotspot, because it uses the same pins to connect from the Raspberry Pi to the hotspot – specifically Pin 7 seems to be available on the top of the hotspot, and can be soldered onto.

The first part of this system is the hardware switch itself.

Looking in my box of spares, and other junk, I found a toggle switch which had a central wiper and 2 other pins. In one position the wiper is connected to one pin and in the other position its connected to the other pin. The 2 “other” pins are not connected to each other at any time (This is important)

To connect the switch to the Raspberry Pi, I needed to find a solder pad on the duplex hotspot that was connected to an unused GPIO pin on the RPi board.

Most duplex hotspots, do not have connections to the entire Raspberry Pi pins, they only have two 10 pin headers, one at each end of the bank of pins on the Raspberry Pi, and of course some of these pins are used for the communication etc between the hotspot and the RPi

Looking on github, I found the original open source design for the duplex hotpot which was used as the basis for the duplex hotspots that are available on eBay and AliExpress from China.

This showed which pins on the RPi were actually used.

Because I also need a 3.3V supply to connect to the switch, I chose Pin 7 (aka BCM4_GPCLK0), as it was close to pin 1 which has 3.3V on it (and also right next to a ground , which I also needed)

In order for the RPi to sense the position of the switch, the voltage on Pin 7, needs to be 3.3V when the switch is in one position and 0V when its in the other position. Although it you could connect Pin 7 directly to the wiper, and 3.3V and 0V to the other 2 pins respectively, its normally good practice to pull up or pull down GPIO pins via a resistor.

In my case I had a 4.7k resistor on my workbench, left over from a previous project, so I decided to use that, but I think the optimum value is normally 10k (but don’t quote me), anyway 4.7k works fine

So I soldered the 4.7k to Pin 7, then connected the switch via  flying lead, where I used red for 3.3V, black for 0V and brown for the switched input Pin 7

After powering up the hotspot, and making sure I’d not done any harm to the board, e.g. like shorting the power rail, I checked that Pin 7 was indeed being switched to have either 0V or 3.3V depending on the position of the switch.

The next step in the process is to make separate profiles for Bransmiester and DMR MARC on  PiStar and add a script to switch between them

To do this you need to login to the PiStar console , by using the “SSH Access” option in the Expert settings.

and create a folder to store the configuration files

using the commands

rpi-rw

mkdir configs

Note.

The command rpi-rw makes the SD card writable, and you may need to use this command again if you find that the SD card becomes non writable – because the RPi operating system seems to run a daemon which keeps changing the SD to read only

The next step is to use the PiStar configuration screen to change to Brandmeister only, e.g. on my case..

Then press the Apply Changes button

Then go back open the SSH Access screen again and copy the active MMDVMHost file to the configs folder

sudo cp /etc/mmdvmhost /configs/bm

Then reconfigure PiStar for DMR Marc using the configuration screen (again), then once the DMR MARC configuration has been installed by PiStar, make a backip of this profile as well

sudo cp /etc/mmdvmhost /configs/marc

Now that you have the 2 configurations backed up, you need to make a script file to check the status of  GPIO Pin 7 and copy the relevant mmdvmhost profile file to the master location and then restart MMDVMHost.

This is the script I created to do this, which can be downloaded from this link  net-switcher.sh

But to get it onto the RPi you can use this command from the SSH window

curl http://www.rogerclark.net/wp-content/uploads/2018/11/net-switcher.sh_.txt –output net-switcher.sh

Now that you have the scripts (in /home/pi-star) you need to make it executable using this command

chmod +x net-switcher.sh

The next step is to test whether the script actually works. by running it in the foreground, by typing the command to run it

sudo ./net-switcher.sh

Depending on the position of the switch , you should see the message “DMR MARC mode” or “Brandmeister mode”

Looking on the PiStar dashboard, you should see the “DMR Master” change (in the lower left corner of that screen).

Note. Although MMDVMHost is restarted and connects fairly quickly, I’ve noticed on IPSC2 and Brandmeister that it takes around 10 secs for the connection to the server to be fully operational.

Now to make this script run when the PiStar starts up.

NOTE THIS CHANGE COULD POTENTIALLY STOP YOUR PISTAR BOOTING IF YOU DO NOT DO IT CORRECTLY.

I used the method described on this page  https://www.dexterindustries.com/howto/run-a-program-on-your-raspberry-pi-at-startup/

Specifically “method 1” which adds the script to /etc/rc.local

To do this you need to edit that file e.g.

sudo nano /etc/rc.local

and add the following line to the second to last line in the file. (just above the line that reads “exit 0”

The text to add is

/home/pi-star/net-switcher.sh &

Once you have added this line and saved the file, all you need to do is reboot (or power cycle) your PiStar hotspot, and after its finished rebooting, you can confirm that the switch is still working by looking at the dashboard

(Note. There are other ways to run a script at boot time, but this method works for me)

For anyone who wants to read the script, here it is

# Script to allow switching of DMR network using a hardware switch
# connected to a gpio pin
# by Roger Clark VK3KYY / G4KYF

# Before using this script you need to make backup copies of your DMR Marc
# and Brandmeister mmdvmhost setting files into /home/pi-star/configs
# the script assumes the files are called marc and bm
#
# You need to make the configs folder
# e.g.
# rpi-rw
# mkdir /home/pistar/configs
#
#
# To create these files. Use the Pi-Star configuration screen to switch to
# DMR Marc, then copy /etc/mmdvmhost to /home/pi
# cp /etc/mmdvmhost /home/pistar/configs/marc
# Then reconfigure to Brandmeister and save that config
# cp /etc/mmdvmhost /home/pistar/configs/bm

#--------- Script code starts here ----------------------------------------

gpio mode 7 in
# Set the lastVal to a non binary value to force the script to copy the
# config set by the switch when the script starts, in case the switch
# was changed when the script was not running, e.g. if the Raspberry Pi was
# not powered up etc
lastVal=-1

#Loop indefinitely
while :
do
b=$(gpio read 7)
if [ $b != $lastVal ]
then
lastVal=$b
#need to mount the file system as read write
#as it defaults to read only

mount -o remount,rw /
if [ $b -eq 1 ]
then
echo "Brandmeister mode"
cp /home/pi-star/configs/bm /etc/mmdvmhost
else
echo "DMR MARC mode"
cp /home/pi-star/configs/marc /etc/mmdvmhost
fi
mount -o remount,ro /
systemctl restart mmdvmhost.service
fi
sleep 1
done