I’ve added a more user friendly power display and control system to the OpenGD77 firmware

Initially the only way to control the Tx power was to set the raw PA drive level number in the Options screen.

Although this was OK for the developers and testers, its was never intended to be the final solution, so today I have implemented a new feature which makes the power control more user friendly.

The power can be set to 250mW, 500mW, 750mW, 1W, 2W, 3W, 4W or 5W.

The power is displayed in the middle of the top of the display.

To change power level.

Press Function + Right to increase power
Press Function + Left to decrease power

Note.
The output power will only be accurate if you calibrate your own radio, because the factory calibration for Tx power hardly ever seems to be accurate.

I checked one of my GD-77’s today and the “Low” power calibration point which is supposed to produce 1W was only producing 0.35W on UHF, and the “High” power calibration point was only producing 3.5W

This is despite the battery being fully charged.

I used the calibration editor in the Community CPS to enter new values for the Low (1W) and High (5W) calibration points, and after I did that, the power output was correct to plus or minus 0.1W according to my power meter.

For those interested in the technical details…

The calibration data stores the Tx Power calibration points for multiple 5Mhz wide frequency bands, for both the High and Low power settings available in the official firmware.

The value stored is 1/16 of the DAC value used to generate the voltage that is fed into an OpAmp, and finally drives the PA FET’s.

For power levels of 1W and 5W I use the values from the calibration table (multiplied by 16).
For 2W, 3W and 4W I assume a linear relationship between PA drive level and output power, and this is reasonably accurate to about plus or minus 0.1W.

If people give me enough data points so that I know that the relationship needs to be slightly modified, I can make minor adjustments to this straight line calculation.

Below 1W, the power curve becomes increasingly exponential, so I’m using my own data points as a offset below the 1W calibration data point.

I doubt that the power output below 1W can be made totally accurate for everyone, but its probably good enough…

This change and the FM DTMF change are in the latest Tier2 file

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

I also made one more small change.

When a DMR call is received, if the call does not contain Talker Alias information which needs to be displayed on the bottom line of the display, either the Channel name or the Rx frequency is now displayed near the bottom of the screen using a small text size.

I initially displayed the Channel name in the same text font size as the Callsign + name, however this looked confusing, so I use the small text font size which is used for the zone name on the Channel screen.

I’ve added a new feature to the GD-77 CPS Community edition to upload firmware

I wrote a standalone Windows exe upload several months ago, to make it easier for the testers to upload the firmware, and because several people asked me whether the CPS could upload the firmware, (like the Anytone CPS does), I finally got around to integrating this feature into the CPS

At the moment this feature has not been extensively tested, so as ever, you use it at your own risk, however I have tested it with the OpenGD77 firmware and also version 3.1.8 of the official firmware, and Clayton VK7ZCR has tested it with multiple different versions of firmware and neither of us had any problems.

The firmware loader is accessed via the Extras menu

Clicking on this will open a file selector popup

Select the firmware file and press Open

This will open the new Firmware loader screen

Press the “Upload firmware to GD-77” button and accept the disclaimer to upload the firmware to the radio

When the firmware has been uploaded, the radio will need to be rebooted as usual

As this version is still in testing, I have not put it in GitHub yet, but it can be downloaded from my website via this link

http://rogerclark.net/opengd77/RadioddityGD77CPS31XCommunityEditionInstaller.exe

I’ve added a feature to import the ‘user.csv’ file into the DMR ID system

With the recent changes to licensing in Australia foundation level operators are now allowed to use digital modes, but the DMR ID download system has not been including the new DMR ID operators because their callsigns are 7 characters long, and the data from hamdigital.org does not seem to include these new callsigns.

I suspect that the hamdigital database can’t handle 7 character callsigns, but whatever the reason, I’ve had to add a new feature so that Australian users can import the full user database from www.radioid.net, filtered by region code e.g. 505.

The entire radioid users database is currently around 145,000 stations, and the limited memory in the GD-77 can only store between 10,000 and 20,000 ID’s depending on how many characters are allocated per ID.

It should be noted that the RadioId database contains a large number of inactive or duplicate DMR ID’s with many stations, me included having more than one DMR ID.
I have one ID for my UK callsign G4KYF and one for my Australian callsign VK3KYY, but often people have multiple ID’s for the same callsign.

Hamdigital.org tracks the number of active DMR ID’s and its much less, with only 30,000 being active in the last month and around 68,000 active in the last year.

Anyway. To resolve this issue, I’ve added a CSV import feature into the DMR ID screen in the CPS CE, which filters the ID’s added to the list by the specified region code; in my case this is 505

After downloading the “user” database file https://www.radioid.net/static/user.csv
Open the DMR ID window and select “Import CSV – filtered by region”
Select the CSV file you downloaded, and the list will be populated with the DMR ID’s callsign and name

As with the DMR ID Download, its possible to import the same CSV file multiple times, specifying a different region code each time.
Its also possible to Download some ID’s from HamDigital and append some ID’s imported from CSV.

This version along with the previous addition of the Firmware loader is now available on Github

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

If your antivirus reports a problem with this file, I also created an alternative installer , which uses a different installer engine and also does not include the OpenGD77 comm port driver installer

https://github.com/rogerclarkmelbourne/radioddity_gd-77_cps/raw/master/NullsoftInstaller/GD77CPSCommunityEditionInstaller.exe

There are currently some problems with the DTMF and 1750Hz Tone deviation, and the DTMF and tone audible feedback through the speaker is too loud

Ray VK3YNV emailed me to say that the DTMF deviation seems to be too high and is causing distortion.

The problem seems to be that the DTMF and Tone require a different master deviation setting to the normal FM audio.

The calibration data contains deviation settings for both of these but we did not use the settings in the OpenGD77 as the DTMF and 1750 tones sounded OK and seemed to work OK.

Anyway, Alex DL4LEX and I are aware of this problem and I think Alex is working on a solution.

With the audible feedback for the 1750Hz tone and the DTMF tones, I think the tones may be louder because the deviation is currently too high.

If after the deviation is reduced the audible feedback is still too loud it would be possible to reduce the overall audio gain on the AT1846S RF chip while the tones are being played.

I have not used either DTMF or 1750Hz in the official firmware, but I think possibly the audible feedback is too loud even on the official firmware, so I could either have a fixed amount of audio reduction when the tone is being played, or perhaps have a setting in the Options menu to control this. However because I don’t think this is something which is a big problem, adding a setting for this is probably overkill

Thanks to Alex DL4LEX the problem with DTMF and 1750Hz Tone burst deviation has now been fixed

Actually its been a group effort… Alex made some changes which I’ve manually incorporated into the master source code, and I had to make a few other changes to get it working correctly..

I also need to thank Ray VK3YNV for testing the deviation levels using his test equipment, and Clayton VK7ZCR for also doing some testing

Also…

Mike KU4ZD reported a problem with the Digital Contact override feature I added a few days ago, where Digital Contacts (TG’s) which did not have the TS set to override e.g. to TS1 or TS2, where not changing the radio back to the TS for the channel.

So I have done a fix for this which Mike has tested and tells me that its now all working OK.

On the subject of the TS override in the Digital Contacts, Mike noticed that if he exported the codeplug dat file to spreadsheet using Colin G4EML’s utilities, and then re-imported the spreadsheets, the override settings had been removed.
I’ve had a look at the spreadsheet created by Colin’s utilities and the problem is that I’m using a “reserved” (unused) byte of data in the Contact data, which Colin is not exporting to CSV or importing.

I’ve emailed Colin asking whether the “reserved” byte could be added to the import and export function in his utilities.

Daniel F1RMB is also now helping with the OpenGD77 project, and has sent me some changes to remove some duplicate code, and he has just sent me some updated to add functions to the display driver API to display circles and triangles and boxes with rounded corners etc.

I’m not sure if we will use any of this in the normal operation of the radio, but they may come in handy.

As usual, I’ve now updated the Tier2Latest SGL firmware file, which can be downloaded from GitHub as usual

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

I have now integrated the Hotspot functionality from the Tier 1 version of the OpenGD77 firmware, into the Tier2 version, and I am looking for responsible beta testers.

I’ve been running the one of my GD-77’s in hotspot mode all day on BM TG91, which is normally quite active, and so far its working OK with no lockups etc

However at the moment I don’t think I’m confident enough that the firmware won’t crash and lock the radio while transmitting, so I do not leave it unattended and I also only have the power set to 250mW, so that even if it did lock while transmitting, it would probably not do any harm to the radio.

One other thing to note is that although the firmware operates in Tier2 mode, the radio only contains one transceiver unit, and hence does NOT operate as either a full repeater or even a duplex hotspot when in hotspot mode.
It only operates as a simple hotspot, like it did in the Tier 1 firmware.

In the longer term, it will probably be possible to make the radio operate as a single frequency repeater, where it listens on TS1 and transmits on TS2, but I will not be able to start work on SRF mode until all the major Tier2 bugs are fixed.

Anyway. If you are interested in testing the Hotspot mode in the Tier2 firmware. Please post a comment leaving you email address and I will try to email you the pre-release version

If anyone has a copy of the December edition of Practical Wireless, I’d be interested to know what they wrote about the OpenGD77 project

PW have not been in contact with me, or with Kai (as far as I’m aware), so I presume they used the publicly available information on my blog, YouTube and GitHub.

Update.

I’ve had a go at reading a blurred image of the article and it looks like was written a while ago as it only discusses the Tier1 version. This is presumably because of the deadlines of magazines going to print.

Some problems were found by several people with the initial test version 0.0.7 so all testers should update to the latest version 0.0.71 and retest

Some, but not all problems that people reported seem to be associated with the host sending Tx and Rx frequencies which were not the same.

This caused the underlying DMR subsystem to think the radio needed to operate in Tier2 Passive mode, like it does when connecting to repeaters.

A legacy of how the official codeplug works, there isn’t a parameter in the Channel data which specifies whether the radio is communicating with a repeater in in Tier2 Passive (semi duplex), or Tier2 Active (simplex operation).

The firmware can only check whether the Tx an Rx frequencies are the same or different, and if they are different the DMR subsystem is put into Tier2 Passive mode (where the repeater is the synchronisation master) and if the frequencies are the same, it goes into Tier2 Active mode (where the GD-77 is the synchronisation mater)

Strangely some programs like BlueDV seem to send Tx and Rx frequencies which have small offsets e.g. 7Hz in one case, but PiStar can also do the same thing, as there seem to be rounding errors in the calculations somewhere in the host system.

You may have noticed sometimes in PiStar, especially with Duplex hotspots, if you enter a frequency eg 439.125 but the page updates and you find the frequency has changed to 439.1249999 . And this casued a problem for the OpenGD77 firmware

Some of the problems in the host software, seems to come from the way frequency offsets are handled. The MMDVMHost communication protocol does not have a way to send the offset frequencies, but instead it simply adds the offset (or subtracts for negative numbers), the offset frequency from the main frequency, and sends the resultant frequency to the hotspot.

This is regardless of which type of hotspot you use.

But this does not cause a problem on the normal simplex hotspot boards, as they only ever operate in simplex mode and analyse the frequencies they are sent.

Anyway. The fix I have put into version 0.0.71 is to take the average value of the Tx and Rx frequencies that are sent by BlueDV or PiStar and use that for both the Tx and Rx frequency.

In the longer term, I probably need to overhaul the DMR subsystem so that the Tier2 mode (Passive or Active) can be controlled separately from relying on comparing the Tx and Rx frequencies, but thats a much bigger change and would potentially cause bugs in the normal operation of the radio.

There was another potential problem where the Rx bandwidth filters could potentially be left set to 25kHz of the radio was on a channel with that bandwidth prior to hotspot mode being entered, so I’ve also fixed that problem in version 0.0.71

I know that 0.0.71 does not fix the problems for everyone, but I’d advise all testers to update to the Tier2Latest as it definitely fixes 2 potential causes of problems

BTW.
I will simultaneously be rolling out other fixes in next few days, but hopefully they won’t impact on the Hotspot mode functionality

Announcing www.opengd77.com a forum for OpenGD77 users

With the large number of operators installing the OpenGD77 firmware, managing feedback from everyone has become difficult so I’ve decided to create a dedicate forum for the OpenGD77 project.

My hosting package allows for multiple separate domains, so I just had to buy the opengd77.com domain name and install the PHPBB forum system on the new domain.

I actually started setting up the site during the week, however I didn’t have time to configure it until today.

I’ll probably continue to make some announcements via my blog when there is a major release to the OpenGD77 firmware and I will be blogging about other topics, but information about more minor releases will be via the forum

UPDATE

Some people have reported not receiving the activation emails from the forum.

This is likely to be because your email client or even possibly your ISP has blocked the email as Spam

If you register with your callsign as your username, I’ll check the list of unactivated accounts and I will manually activate any which have a callsign and hence are not likely to be a spambot

Some people have reported that the CPS is not automatically detecting the OpenGD77 com port even though the drivers have been loaded.

In an attempt to provide a workaround for this instance I’ve modified the CPS, so that the OpenGD77 support screen will show a Com port selector popup if the OpenGD77 com port is not automatically detected.

This test version can be downloaded from here

https://drive.google.com/open?id=1Z5ry0Nuh9UtNCOMklVSz_G-3NJheHEIA

I’d appreciate it if anyone could try this version even if their OpenGD77 is being automatically detected, to confirm I have not broken the existing detection functionality

In addition this version also remembers the last directory you opened a firmware file from, which will make it easier for users when uploading firmware to the GD-77 from this feature in the CPS

The OpenGD77 forum is currently offline, because the update to PHPBB 3.0 failed due to an incompatibility with the PHP version on my hosting.

I’m currently trying to resolve this problem

I’ve added a more user friendly power display and control system to the OpenGD77 firmware

Initially the only way to control the Tx power was to set the raw PA drive level number in the Options screen.

Although this was OK for the developers and testers, its was never intended to be the final solution, so today I have implemented a new feature which makes the power control more user friendly.

The power can be set to 250mW, 500mW, 750mW, 1W, 2W, 3W, 4W or 5W.

The power is displayed in the middle of the top of the display.

To change power level.

Press Function + Right to increase power
Press Function + Left to decrease power

Note.
The output power will only be accurate if you calibrate your own radio, because the factory calibration for Tx power hardly ever seems to be accurate.

I checked one of my GD-77’s today and the “Low” power calibration point which is supposed to produce 1W was only producing 0.35W on UHF, and the “High” power calibration point was only producing 3.5W

This is despite the battery being fully charged.

I used the calibration editor in the Community CPS to enter new values for the Low (1W) and High (5W) calibration points, and after I did that, the power output was correct to plus or minus 0.1W according to my power meter.

For those interested in the technical details…

The calibration data stores the Tx Power calibration points for multiple 5Mhz wide frequency bands, for both the High and Low power settings available in the official firmware.

The value stored is 1/16 of the DAC value used to generate the voltage that is fed into an OpAmp, and finally drives the PA FET’s.

For power levels of 1W and 5W I use the values from the calibration table (multiplied by 16).
For 2W, 3W and 4W I assume a linear relationship between PA drive level and output power, and this is reasonably accurate to about plus or minus 0.1W.

If people give me enough data points so that I know that the relationship needs to be slightly modified, I can make minor adjustments to this straight line calculation.

Below 1W, the power curve becomes increasingly exponential, so I’m using my own data points as a offset below the 1W calibration data point.

I doubt that the power output below 1W can be made totally accurate for everyone, but its probably good enough…

This change and the FM DTMF change are in the latest Tier2 file

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

I also made one more small change.

When a DMR call is received, if the call does not contain Talker Alias information which needs to be displayed on the bottom line of the display, either the Channel name or the Rx frequency is now displayed near the bottom of the screen using a small text size.

I initially displayed the Channel name in the same text font size as the Callsign + name, however this looked confusing, so I use the small text font size which is used for the zone name on the Channel screen.

With the OpenGD77 firmware Talkgroups are assigned to Channels, and the VFO, using a Rx Group list, however on DMR MARC and DMR+ networks, different TalkGroups operate on different Timeslots.

EDIT.

There was initially a crash bug in this version. So I had to withdraw it.

I’ve now, hopefully fixed the bug and updated the Tier2 Latest version so that it can be downloaded.

———————————————– Original Article continues ————————————————-

To overcome the need to remember which TimeSlot is required for each TalkGroup / Digital Contact, I’ve now modified both the Community CPS and the OpenGD77 firmware, so that there is an option to assign a Timeslot to a Digital Contact.

By default Digital contacts will have the Channel TS/ Repeater Slot override disabled, so everyone’s existing codeplug will continue to operate as befor

However if a Repeater Slot (TS) override is selected; when the Digital contact is used by the OpenGD77 firmware e.g when selected in the VFO or a Channel, the Repeater Slot (TS) value associated with the TG will be applied to the Channel or VFO as an override to either the TS assigned to the Channel and will also override the manual TS change made by pressing the Star key

In instances where you are using different networks which require the same TG on different Timeslots, I have also modified the CPS to allow creation of multiple Digital Contacts with the same TG number.

For Example.
I need TG 505 on both TS1 and TS2. So I have created 2 Digital Contacts with the Call ID of 505, one called “TG 505 TS1”, which has the TS set to 1 and another called “TG 505 TS2” which has the TS set to 2.

For TG’s like 9, where they are general purpose and I may use them on either TS, I just have one Digital Contact, but the override setting is set to “Disabled” so that selecting this TG will not change the current TS on the Channel or VFO.

Note.
This feature has no effect on the official Radioddity firmware, because I use an part of the Digital Contact data structure which the official firmware does not use, and also I do not change the value in the default data unless the dropdown menu of changed, to either TS1 or TS2.

To use this feature, download the latest Community CPS installer e.g
https://github.com/rogerclarkmelbourne/radioddity_gd-77_cps/raw/master/installer/RadioddityGD77CPS31XCommunityEditionInstaller.exe

And install the Tier2 Latest OpenGD77 firmware

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

Update.

I’ve had reports of the firmware constantly rebooting under some circumstances.

The problem seems to be something to do with the settings that the firmware stores in the EEPROM.

If this happens…

1. Turn off the radio.
2. Press and hold the Blue button on the side of the radio
3. Turn on the radio and wait for it to boot-up
4. Release the Blue button

The settings should now be reset and the radio should not keep rebooting.

Thanks to Alex DL4LEX, FM DTMF for the OpenGD77 is now functional

—————————– Update 8th November —————————–

VK3YNV has been some tests of the DTMF and it looks like the tones are currently over-deviating the FM modulation.

This probably apples to both the DTMF and the Tone burst and possibly also to the CTCSS tones

I’ve done some initial investigation of the problem, and calibration values for the DTMF, Tone burst and CTCSS value are not being read from the Flash memory and being applied

The data sheet does not seem to contain any information about how to set the DTMF or Tone burst deviation, but its possibly the same register as the CTCSS control register settings.

I will need to do some R&D during the weekend
—————————- —————————- —————————- —————————-

DTFM tones can be transmitted on FM by pressing the number and other keys on the keypad.

There is also audible feedback though the speaker.

Alex also sent me another modification, which I discussed with him.

If the TalkGroup has been entered manually, pressing the Left or Right arrow keys first removes the manually entered TalkGroup.
Then pressing Left or Right again, cycles through the TalkGroup list as normal.

I have updated the Tier2 latest version with this and other changes

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

I’ve been investigating solar power options for some external monitoring devices, so I invested in three (3)  “5V 1W” solar panels from eBay,  the amazing price of  $1.69 AUD each (around $1.20 USD or £1 UK), not really knowing what to expect.

When the panels arrived, the first thing I noticed as that the solar collector on each of them, didn’t quite look the same.

Also, one of them had distinct bulges of what appears to be excess resin, down the center line of the panel

Nevertheless, I connected them to my trusty analog multi-meter, so that I could easily test both the voltage and current output from the panels (but not voltage and current at the same time)

In the bright Australian sun, all the panels produced just over 6V when offload, and produced in excess of 250mA when the meter was switched to its current setting.

This was a promising start, but of course the panels would not be producing 250mA at 6V, as that would be 1.5W not 1W as claimed in the eBay listing.

To get an idea of the actual amount of power (W) that these panels are capable of producing, you need to apply an optimum value of load, so that output voltage x output current = maximum wattage.

In commercial solar controllers, this load is provided my a “Maximum power point tracking” controller https://en.wikipedia.org/wiki/Maximum_power_point_tracking  which optimises the amount of current being drawn from a panel to produce the maximum power,

But as I don’t have a MPPT controller capable of operating on a 5V 1W panel, the next best thing is to apply various load resistors to find when the output voltage drops to its specified nominal output of 5V.

Using this method, I found the optimum resistance that still produced 5V from the panel was somewhere around 30 ohms. (33 ohms gave just above 5V and 27 ohms gave just below 5V)

Hence, I’ll assume that in ideal conditions that a 27 ohm resistor in parallel with the panel would give 5V output, and hence a current of 185mA and total power of 0.92W

This is a much better result than I expected for a panel in this price range, so I’m happy with this purchase and may buy a few more of the same type of panel.

Of course this is really just half the story in terms of powering a microcontroller with transmitter etc, so the next stage in this project will be to determine the best way to charge a 3.7V LiPo cell using this panel, so I will post again when I’ve sound a solution to this problem.

In my previous post, I reviewed some “5V 1W” solar panels, with a view to using them to power some IoT devices, and in this post I’ll show my experiments and conclusions about using the panel to charge the battery.

LiPo cells have specific charging and usage requirements so that they don’t get damaged.  For charging the basic principal is that they require both constant current and then constant voltage charging. They also should not be overly discharged or float charged.

The test setup…

I’m using an analogue meter in series with the 2200mAH LiPo battery, set to its 250mA current range.

I used an analogue meter because it responds quickly to changes and is accurate enough for this sort of testing.

The variable resistor attached to via the orange and yellow wires, is to control the charge current on the TP4056 LiPo charger module. (see Charging Option 4 )

The variable resistor connected by the 2 yellow wires, controls the output voltage from the LM2596 DC to DC converter module.

The switch allows me to connect the battery to either the input or output of the TP4056 LiPo charger.

Note. There is a capacitor which appears to be soldered onto the input of the DC to DC converter.

Its actually only soldered on the positive terminal, and the negative terminal can be connected my pressing its wire onto the PCB.

I tried most configurations with and without this 2200uF capacitor and I didn’t see any noticeable difference in the charge current  etc.

Capacitor on output of solar panel

Charging option 1.

If you disregard the “not float” charged requirement, one option is simply to connect the LiPo battery to the solar panel, via some diodes, or a zener diode, which would limit the maximum voltage to around 4V (most batteries seem to require charging to 4.2V)

Offload the solar panel reaches around 6.5V, so a circuit which “drops” around 2.5V would be required.

I found some 1A diodes can drop around 0.8V, so 3 diodes in series would “drop” 2.4V, which should be sufficient to prevent the battery being overcharged.

However in practice this solution is the worse of all those I tried, mainly because the efficiency of the panel drops a lot as its voltage increases above 5V and also the diodes dissipate around 2.4 * 0.15 = 0.36W of power

(Power = Voltage * Current)

Charging option 2

Clamp the output of the solar panel so that if the voltage exceeds 4.2V.

The simplest clamp is to use a zener diode which is capable of handling the maximum current that the panel can produce. So a 250mA zener would have plenty of current capacity to spare.

This option charges the battery much better, because the solar panel is much more efficient at voltages below 5V than it is above 5V, and even at 3V, the battery was charged at around 150mA, and as the battery voltage increases the amount of power (voltage x current) being put into the battery increases.

e.g. 3V @ 150mA = 0.45W

4V @ 150mA = 0.6W

This method worked well, but did not seem to be the optimum solution, because the solar panel was not operating at its most efficient voltage (of 5V), hence in the worst case, the battery is being charged at 0.45/0.75 of maximum efficiency (assuming the panel can produce at least 0.75W under ideal conditions, with 33 ohm load)

Which led me to evaluate the next option.

Charging option 3

Connect the output of the solar panel to a DC to DC “buck” voltage regulator converter (which use the LM2596) , which can be found on eBay for $1 or less

The reason to potentially use this module, is that it can convert the DC input voltage to a different (lower) DC voltage without as much loss as a linear regulator or resistor or diodes.

However in practice when I connected the module between the solar panel and the battery, I found that the charge current which has been around 150mA for a direct connection, dropped to around 125mA or less.

To add a bit more detail, what I did was connect a voltmeter to the input of the module (from the solar panel), and adjust the output voltage until the load on the solar panel reduced its voltage to around 5V

To make this a bit easier I removed the small trim-pot variable resistor and attached a normal pot on some flying leads.

This wasn’t what I expected to happen, so I looked in the data sheet for the LM2596 at the expected efficiency, there is a graph of the efficiency with a 3A load

The load of the battery is about 20 times less than illustrated on the graph, but the graph implies that potentially the efficiency when the input and output voltages were low e.g. 5V in 3V out, was not very good, and potentially could be less than 70%

To confirm the efficiency, I did some tests using a bench power supply set at 5V, a 150ma load using a resistor; and measured the input and output currents for a series of output voltages, from 3V to 4V. The results were fairly consistent with an efficiency of 75%

The results seem to agree with what I observed when I connected the DC-DC converter to the solar panel, except the efficiency may be even lower than in the controlled environment, and may be as low as 60 to 65%

With these low efficiencies, using this particular DC to DC converter is pointless, as its less efficient than simply loading the solar panel to a voltage where its efficiency is not optimum.

It could be that a different type of DC to DC converter may be more suitable to low voltage operation (5V input) and where the input and output voltages are just 1 or 2 volts different.

For example the MP1484 has a claimed efficiency of 80%, with input of 5V and output of 3.3V

See   http://www.mouser.com/catalog/specsheets/MP1484.pdf

But even 80% isn’t that good, and is probably only 10% more efficient than the panel its self.

Hence, using a switching DC to DC converter for this small panel does not seem practical.

Charging option 4

Use a LiPo management module which uses a TP4056 for charging

The TP4056 is a “A Standalone Linear Li-lon Battery Charger with Thermal Regulation”

See https://dlnmh9ip6v2uc.cloudfront.net/datasheets/Prototyping/TP4056.pdf

The charging current of these modules is set to 1000mA by default, because resistor R3 is 1.2k ohms, however the charge current can be adjusted to a much lower value if the resistor is replaced by one of a higher value, and could potentially be controlled by replacing R3 with a transistor.

I found several posts on the web, where people had been trying to use these in conjunction with a solar panel, and wanted to adjust the current so that the panel maintained its maximum efficiency voltage (of around 5V).

However, because the TP4056 is a “linear” device, maintaining maximum efficiency at 5V does not necessarily yield the best charging methodology.

For Example.

At 5V the panel can produce 150mA, but as the TP4056 the most current it can deliver to the LiPo cell is the same as its input current, i.e 150mA

The difference in input power (5 x 150ma = 0.75W) and the output power (3V x 150mA = 0.45W) is just dissipated in heat.

Also, this module would need considerable modification, probably involving one or 2 external transistors and 2 or 3 resistors, in order that the charge current was modulated to maintain the input voltage from the solar panel at 5V

So following a hint on another forum, I decided to simply replace the current control resistor (R3) by a 10k variable resistor, and monitor the charge actual charge current to the battery, as the resistance was varied.

Modified LM2596 DC to DC converter moduleTo my partial surprise, I found that there seems to be an optimum resistance value which gives the most charging current under most light conditions.

The resistance required is the value needed for a charge current of 150mA, which seems to be around 8k.

In full sunlight, if the resistance value was adjusted to be higher than 8k, the charge current was limited by the TP4056 to a lower value e.g. 10k gives around 130mA.

If a significantly lower value of resistance was used, the charge current also diminished below the optimum, but this effect was not as marked as higher resistances than 8k, and I am not entirely sure why this happened, but I could start to hear a high pitched whistle from the module, so I think that the increased current was causing the voltage from the solar panel to drop too low for the TP4056 to be able to charge the battery, at which time it stopped charging, and the voltage from the panel rose to where the TP4056 would operate again.

This oscillating operation is not as efficient as just using around 8k resistance.

Strangely at lower light levels the oscillation does not seem to occur even though the charge current is much lower.

In conclusion

For the configuration I investigated, the best option in my opinion, is to use a TP4056 based battery management module, preferably one which has separate battery and output terminals, so that its impossible to completely discharge the LiPo cell.

Then simply replace resistor R4 3 with one that gives the correct maximum charge current.

Trying to increase the efficiency of the overall system by using a DC to DC converter only gives a very marginal improvement, and the cost of the DC to DC converter e.g. $1 is over half the price of the solar panel, so it is more economic to spend $1.50 to buy another panel and put it in parallel hence doubling the charging capability.

Update 15th Nov 2017

I’ve been sent some interesting new information, including a link to this great video by Andreas Andreas Spiess

And a great comment about using the CN3791. So I’ve ordered 2 of those modules for testing.

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

Edit. The P and 5 are actually “SP” for speaker. The Pin labelled S (or 5) connects to the PCB pad closest to the pin header, and the pin labelled P connects to the pad nearest the end of the board (i.e the furthest  from the pin header)

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.

I found this Chinese datasheet

https://cdn.datasheetspdf.com/pdf-down/I/P/5/IP5306-Injoinic.pdf

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.

The module also has a SD card, but according to the available information, the SD card appears to be connected as an SDIO device rather than a SPI device.

The pinout shows only 4 pins being connected to the SD card. CMD (IO 15), CLK (IO 14), DAT0 (IO 2) and DAT1 (IO 4)

I’m not entirely sure what this SD card configuration is.

The Arduino STM32 core has a SD MMC library which defaults to 4 bit, but I don’t think that’s what this is.

So I’ll need to do some more research.

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.

Update

I connected a 2000mAh LiPo battery to the board’s battery terminals and the battery powers the board, and it does appear to charge the battery if I connect the USB.

However, the board draws around 125mA even with a simple program doing nothing. I think it would take more if the program was using WiFi.

I tried using some of the Arduino deep sleep examples, and there seems to be a problem using them using a battery connected to the battery terminals.

What seems to happen is that after around 35 seconds after the ESP32 entered deep sleep, the battery charge / monitor chip, senses that the ESP32 is not taking much current, and seems to completely turn off the voltage to the ESP32.

All LED’s on the board go out.

I’ve tried using the deep sleep examples that wake from external interrupt and also from a timer, but neither of them work,  and the ESP32 does not appear to wake up once the battery controller has timed out.

I’m a bit surprised that this is happening.

I find if I press the Reset button (the button on the right), that power is restored, but the reset button doesn’t seem to work very well, even when power is applied to via USB, so I’m not sure if the problem with waking up via the reset button is the button its self or not.

Its difficult to read the data sheet for the battery controller, as its in Chinese, but I can’t see anything obvious which would allow the ESP32 to control the battery controller, perhaps to allow just the ESP32 to be powered and not the rest of the board

Update 6th Oct 2018

I found a youtube video by G6EJD called “Tech Note 099 “…. and he had some useful information about the SD card connections.

The card is connected via SPI but not on the pins that the official Espressive Arduino core uses for its SPI SD connections

He linked to a library on github ( https://github.com/LilyGO/esp32-micro-sdcard ), which works for this board, because you can set the pins

SS GPIO 13

MISO GPIO 2

MOSI GPIO 15

SCLK GPIO14

however since this is a standard SPI connected SD card, I looked at the official SD library and also the official SPI library, and found that the SD library begin function can be passed an instance of SPIClass and the SS pin.

So the simple fix for this is to replace the Sd.begin() call with

SPIClass sdSpi;// make our own special instance of the SPI class
sdSpi.begin(14,2,15,13);// Set the pins we need
SD.begin(13,sdSpi);// setup the official SD class using our SS pin (13) and also our instance of the SPI class

Changing these lines in the official Arduino core, immediately resulted in the SD card being recognised and the demo was able to read and write files etc.

I have noticed one problem, with the demo, in that (1) it seems to have a bug where it attempts to delete the file “hello.txt” just after it renames hello.txt to foo.txt

Also, it seems to give an error saying its unable to “open a file for reading” but I’m not sure what file its trying to read, as the demo already successfully opened and read in both hello.txt and foo.txt

I did try changing the SPI speed from the default to 10,000,000 but this didn’t seem to make any difference, so I suspect the problem may be in the demo code rather than some specific problem on this board.

The other useful thing that G6EJD said was that there is a green “user” LED on pin GPIO 22

And… In the comments, a lot of people had also found that its impossible to use this board in low power (deep sleep) mode, because the battery manager chip turns off the power to the ESP32 after about 45 seconds (I found this was nearer 35 seconds)

I’m still trying to find a solution for this, because turning off the power to the other peripherals is a good idea, but not to the ESP32. So ideally there would be an alternative route for power to be supplied to the ESP32 when its in deep sleep mode.

One thought I had was to bypass the battery manager chip using several diodes and a resistor in series.

This may be able to provide just enough current to keep the ESP32 running, however there are a couple of problems with this…

1) Other devices e.g. the audio amplifier and the buck converter etc, are probably powered from the same 3.3V rail, and would take power from this bypass route

I’d need to check what is connected to the 3.3V rail that feeds the ESP32, and possibly put a low voltage drop diode in series with its supply track to prevent back feeding.

2) When the ESP32 wakes from deep sleep, it would suddenly require a load of current, and it will take some time for the battery manager chip to respond to the demand, and turn the power back on.
This may cause the ESP32 to brown out and potentially just reboot.

Assuming that I’ve fitted a diode to prevent back feeding of the deep sleep power , just to the ESP32, then a capacitor could possibly be added next to the ESP32 with enough capacity to sustain it for the time it takes for the power management chip to wake up.

Update 7th Oct 2018

I had another look at the datasheet for the IP5306 battery manager chip, and even though the datasheet is written in Chinese, its clear that this chip is designed for those mobile phone “power bank” devices, as the example schematics all have the output connected to USB sockets (2 sockets).

It looks like the chip produces 5V from the 3.7V Lipo cell, so I suspect that the EA3036 produces 3.3V from the 5V generated by the IP5306

I measured the voltage on the audio amplifier IC, and it seems to be supplied with 3.3V. So as far as I can tell the 5V output from the IP5306 is not directly used by anything,

The EA3036 has some low power modes, which seem to be controlled by some “enable” pins, but as far as I can tell, the enable(s) seem to be connected to the Vin pins, as it looks very much like EN3 and IN3 are connected .  EN1 and EN2 seem to be connected together, but don’t seem to be directly connected to IN1 or IN2.

Buck converter 3 pins are on the side of the chip closest to the ESP32, so my guess would be that perhaps that buck converter 3 powers the ESP32.

Possibly buck converters 1 and 2 power the audio amplifier, because it can draw over 1A (as its a 3W amplifier)

I’ve yet to try adding a bypass power route to give the ESP32 enough power when in sleep mode, but I have a feeling that it may be better to disconnect the existing battery management system, and use a separate module; though I’m not sure which module.

The problem with most battery changer modules is that they have an almost direct output from the battery voltage, which is nominally 3.7V and can be as high as 4.2V, so some kind of step down regulator is required to supply the power to the ESP32.

If the audio amplifier was required, it would be best to power this directly from the battery module as it can operate from up to 6V.

Additionally the amplifier has a low power shutdown mode,where it only draws 0.1uA, if its “Control” pin is pulled low.
On the module the Control pin seems to be pulled high through a resistor, so I think the best solution would be to pull this low though a resistor e.g 10, and then use one of the GPIO pins on the ESP32 as the amplifier control, so that the ESP32 could turn on the amplifier when its needed.

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.

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 DMR MARC 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/marc

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

sudo cp /etc/mmdvmhost configs/bm

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 > 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

I’ve been experimenting with various ways to display information on my PiStar based hotspot, including the small OLED displays.

I found the the OLED is to far to small, so I splashed out and bought what I thought was an official Nextion 2.4 inch display, from a eBay vendor.

I was aware that there are clones of the Nextion, which don’t work with the official Nextion editor and don’t accept data files produced by the official Nextion editor.

But I specifically ordered a board which looked like a Nextion made by Itead and had a Nextion part number (beginning with NX)

The photo on the product I ordered looked like this.

When the display arrived, I noticed that the PCB did not match the photo in the eBay listing, but it did have the correct model number and also had what looked like the Nextion logo.

Clearly the board is completely different, despite seeming to have identical model numbers.

I became suspicious about whether this board was an authentic Nextion,  when I was unable to upload the “TFT” configuration files via SD card.

The upload always stopped whilst displaying “SD Card Update…..” rather than going on to copy the graphics and configuration data from the SD card.

Assuming there was something wrong with the “TFT” file I got from the web, tried connecting the display via a USB to serial converter to my PC,  and I managed to use the official Nextion editor to upload a set of screens I downloaded from the MMDVM github account (G4KLX)

The display then seemed to work OK with PiStar, but I thought I’d try a different screen layout, and this is when the problems started …

When I tried to upload the new layout using the Nextion editor and the USB to serial adaptor, I found that the Nextion editor would no longer connect to the display.

However, when I reconnected it to Pi Star, I found it was still working.

Not to be deterred, I thought I’d try to upload via SD card again, and after trying various micro SD cards, I eventually found an old 4Gb card, which was probably 4 years old, which was recognised by the display, and I was able to upload a different layout.

After removing the SD card and removing and reconnecting the 5v input to the Nextion, the new layout worked OK, but unfortunately this was the last time I was able to use the display.

Because I thought I’d try another different screen layout, and after uploading that layout using the micro SD card, when I removed the SD card and removed and reconnected the 5v input to the “Nextion”, I found it was no longer receiving any data from PiStar.

Just in case something had happened to my hotspot board, I connected the USB serial adaptor to the Nextion output on the hotspot and used a terminal program on the PC to confirm that the hotspot was still sending serial data to the display.

Currently I have no idea whether this board was an official Nextion or not. I didn’t buy it direct from ITead (my mistake), and instead bought it from an eBay vendor in China, via eBay, because the vendor offered free shipping.

The vendor claims it is an authentic Nextion, but offered $4 compensation, which I rejected because I’d rather give negative feedback on eBay and warn other potential buyers that these boards may not be genuine.

My advice to anyone who is thinking about attaching a Nextion to their PiStar hotspot, is to buy direct from ITead, even though its likely to cost $10 more (about 30% more) than from third party vendors, because you are guaranteed to get a genuine board, and are also likely to get support from ITead if you end up having the sorts of problems I’ve had.

Even if my board was not genuine, I still don’t understand why it failed.

What appears to have happened is that initially the serial Tx line probably stopped working, hence the Nextion editor would not connect to the display, but the display still seemed to work when I connected it to my hotspot, since PiStar only sends data to the display and does not expect a response from the display

Subsequently, I think the Rx line into the display probably also failed.

I’ve used STM32 microcontrollers a lot, and I’ve never had a problem before with the serial Tx and Rx lines, even if I connect them the wrong way around. So I find it surprising that the serial lines on this STM32F030 have failed one after the other.

I did not disconnect the serial Tx and Rx lines from the hotspot, when I removed and reconnected the 5v input wire, to the display, when I was uploading via micro SD card, but again I have never had a problem with other STM32’s with leaving input signals connected when the MCU is not being powered.

However perhaps the STM32F030 used on these nextion’s is not very robust, and leaving the serial wires connected when I power cycled the display was enough to damage them.

Now that I’m left with a “bricked” display, I’m going to try to connect to the 5 pads on the back of the PCB, which I presume are the SWD debugger / programmer connections, but I’m going to need to work out which pads are which connections, because the Nextion is not open source and there is no documentation about what these pads are connected to.

Hopefully I’ll be able to use the screen for something, but for the moment its going into my junk box