Thursday, May 28, 2020
Upgrading Raspberry Pi3 - addendum
I upgraded my Pi3B+ to Raspi Buster, that was fine, later I thought to update the packages from the System menu, it showed there was 1050 packages to update, so kicked it off, running for a while, got to about 80% completed, then stopped, after that no activity, I let it sit there for an hour or so, still no further progress, could not get response back of the menus, so eventually pulled the power cable for the Pi 3, plugged it back in, up it came, except it now in command line modes, peruse the folders, looking very empty. Desktop files gone, oh, well, I had not lost anything, as I was still testing and learning how to use it. Next, I discovered a blog with a complete image for running Direwolf iGate APRS gateway, which is what I wanted to do. I have now started on that. More to follow.
Covid-19 Isolation radio net
over the past 8 or so weeks, while working from home, I been listening to the Isolation Net which is operated by Simon VK3XEM in Ballarat, via the VK3 AllStar network. The AllStar network is network of FM voice repeaters across VK3 and up to Albury, includes IRLP and Echolink nodes and a Gateway onto digital modes, so I have been accessing that network listening to the net each morning via Brandmeister DMR TG 50525 which ports to the VK3GWY Digital gateway.
The net is just to allow hams to keep in touch with each other during the Covid-19 pandemic, and Simon calls for checkins for all on the net which is held from 10am AEST Mon-Fri. I haven't checked-in myself, but nice to listen in whilst I working from home and hear from many on the net, mostly country and regional stations, but there are stations that drop in from overseas and interstate and they are all welcomed by Simon VK3XEM.
I been impressed by the VK3 AllStar network, during the rest of the day I can hear the locals (mostly country VK3) going about their business on the network which comes through to Brandmeister DMR TG50525.
Note: if you should access the VK3GWY Digital gateway via a digital mode (P25,NXDN,YSF,DMR) remember to leave 3-4 seconds between overs to allow the digital and analogue repeaters to drop after each over.
Follow the link below for the network map.
VK3RBA network info on QRZ.COM
The net is just to allow hams to keep in touch with each other during the Covid-19 pandemic, and Simon calls for checkins for all on the net which is held from 10am AEST Mon-Fri. I haven't checked-in myself, but nice to listen in whilst I working from home and hear from many on the net, mostly country and regional stations, but there are stations that drop in from overseas and interstate and they are all welcomed by Simon VK3XEM.
I been impressed by the VK3 AllStar network, during the rest of the day I can hear the locals (mostly country VK3) going about their business on the network which comes through to Brandmeister DMR TG50525.
Note: if you should access the VK3GWY Digital gateway via a digital mode (P25,NXDN,YSF,DMR) remember to leave 3-4 seconds between overs to allow the digital and analogue repeaters to drop after each over.
Follow the link below for the network map.
VK3RBA network info on QRZ.COM
Monday, May 18, 2020
doing a Raspian upgrade on my Raspberry Pi3
I had this Raspberry Pi3 for a while now, but never upgraded, so it is time to learn, a few simple commands from the command terminal shell :
sudo apt update to make the device check for updates over the web.
sudo apt list to see what packages are upgradable
sudo apt dist-upgrade to make it install the updates. it will prompt you Y/n to continue or not.
sudo rpi-update update the RPI firmware
sudo apt autoremove to clean up old packages
sudo apt clean to clean up un-necessary cache and files remaining after the upgrade.
sudo reboot to restart the device
Then to System Tools > Package Update (may have to add this option to the System Menu)
sudo apt update to make the device check for updates over the web.
sudo apt list to see what packages are upgradable
sudo apt dist-upgrade to make it install the updates. it will prompt you Y/n to continue or not.
sudo rpi-update update the RPI firmware
sudo apt autoremove to clean up old packages
sudo apt clean to clean up un-necessary cache and files remaining after the upgrade.
sudo reboot to restart the device
Then to System Tools > Package Update (may have to add this option to the System Menu)
Wednesday, May 13, 2020
Radiodity GD-77 DMR handheld firmware and CPS
following on from my experiences with almost bricking my handheld, I thought I better add the versions of firmware (with respect to the hardware level of my handheld) to avoid costly mistakes.
First, there are now multiple versions of the hardware for the GD-77, mine looks to be the original hardware, so it can only works with specific firmware and CPS (Codeplug Programmer) versions and the combinations are critical, in other words, you need to be using the correct version of CPS that matches your firmware.
What my handheld was using up until recently was firmware 3.00.06, DSP HRC6000 v1.2 and CPS 3.1.1, my serial no of my handheld is 1805A00096 which means built 2018-May.
I was using wrong CPS version with respect to my installed firmware.
Release Dates:
2017xxxx 20180619 20180623 20190125 20190425 20191108 20191204
Firmware versions:
3.0.6 3.1.6 3.1.8 3.2.1 3.2.2 4.2.6 4.2.8
Firmware Dates:
2017xxxx 20180330 20180623 20190125 20190425 20191108 20191204
CPS versions :
2.0.5 3.1.1 3.1.1 3.1.1 3.1.1 3.1.9 3.1.9
F/W Updater : v103_170830 same for all these versions above.
Radiodity downloads
One thing I noticed was from CPS 3.1.1 it is meant to provide 31 channels instead of 16, but I am using f/w 4.28 and CPS 3.1.9 and still limited to 16 channels, Contacts has increased and Scan list increased.
And thanks to Roger Clarke VK3KYY, from his blog it gave me the clues to fix my GD-77.
Roger is also involved in a Community created alternative firmware for these handhelds. Worth having a look at, if you don't like the provided firmware functionality.
First, there are now multiple versions of the hardware for the GD-77, mine looks to be the original hardware, so it can only works with specific firmware and CPS (Codeplug Programmer) versions and the combinations are critical, in other words, you need to be using the correct version of CPS that matches your firmware.
What my handheld was using up until recently was firmware 3.00.06, DSP HRC6000 v1.2 and CPS 3.1.1, my serial no of my handheld is 1805A00096 which means built 2018-May.
I was using wrong CPS version with respect to my installed firmware.
Release Dates:
2017xxxx 20180619 20180623 20190125 20190425 20191108 20191204
Firmware versions:
3.0.6 3.1.6 3.1.8 3.2.1 3.2.2 4.2.6 4.2.8
Firmware Dates:
2017xxxx 20180330 20180623 20190125 20190425 20191108 20191204
CPS versions :
2.0.5 3.1.1 3.1.1 3.1.1 3.1.1 3.1.9 3.1.9
F/W Updater : v103_170830 same for all these versions above.
Radiodity downloads
One thing I noticed was from CPS 3.1.1 it is meant to provide 31 channels instead of 16, but I am using f/w 4.28 and CPS 3.1.9 and still limited to 16 channels, Contacts has increased and Scan list increased.
And thanks to Roger Clarke VK3KYY, from his blog it gave me the clues to fix my GD-77.
Roger is also involved in a Community created alternative firmware for these handhelds. Worth having a look at, if you don't like the provided firmware functionality.
Saturday, May 9, 2020
DMR - upgrade Pi-Star for JumboSpot MMDVM
Continuing on with the upgrade of my MMDVM, today upgraded the Pi-Star firmware from 3.4.12 to 3.4.17, I decided on the 3.4.17 as I just wanted to try and have a look at the last 3.x.x version of Pi-Star before moving onto 4.x.x, as the version 4.x.x has a RasPi O/S upgrade as part of the release, so it is significant change. When upgrading your Pi-Star image, make sure you backup your Pi-Star configuration, it easy to do from the Pi-Star admin console, see Backup & Restore, the backup saves all your config into a ZIP file. This allows you to install a new Pi-Star image file onto a micro SD card, ie 8GB, install it into the MMDVM unit and then once you connected and access the Pi-Star admin console, you can then use the Restore menu to import the configuration file into the new Pi-Star image. You might have to make some minor fixes to the configuration like the wifi config and DMR system selection, but the bulk of the configuration gets loaded. To be sure , you retain everything config related, just screenshot your Configuration menu before installing the new Pi-Star image. And when your upgraded Pi-Star is up and running don't forget to update the Pi-Star Dashboard software, as of today it is version 20200507
Pi-Star homepage
Pi-Star homepage
Friday, May 8, 2020
flashing TV and Media Center
I flashed new firmware to a LG 32LN5400-TA LCDTV last night, that was easy, just downloaded latest firmware file from LG, unzipped the image file, stuck it on a USB memory stick, in a folder called LG_DTV or similiar, plugged it in USB socket of the TV and away it went and pretty much installed itself and it was updated. v03.30.31
Next I wanted to upgrade my Minix NEO X8H Plus Media Center, that is Minix the hardware company, not Minix the POSIX/UNIX O/S. Anyway, this Minix box came with Android 4.4 and XBMC Media Center application, for watching movies, interfacing with PVR apps, TV, Music, player and manager. XBMC became Kodi, which is well known in Linux world as a media player and content manager. I bought this little box a few years ago, to interface with the TV and watch internet TV, but in recent years those TVs replaced by Smart TV's, so I can do all that internet TV stuff much faster and easier from the LG Smart TV's, so the little Minix box started collecting dust.
Recently, I was curious to see if others had put these Media Centers to other uses and a bit of searching yielded many results, people use these little boxes as game consoles, by replacing the O/S with other customised Linux based spins onto these boxes as retro Game consoles, or combination media center and games consoles, but if I wanted a games console, I'd just go buy a Xbox or Playstation. Anyway, coming back to the Minix box, I found some forums and in particular the Minux forum and people were upgrading them to get the latest functionality of Kodi, so I thought I have nothing to lose but upgrade the box to Android Lollipop 5.1.1 from the original KitKat 4.4 and put later Kodi player on.
Upgrading the Minix NEO X8H Plus unit was damned easy, the forum spelled out the procedure in half a page, two URLS, one for the USB burner utility, which is used to upload the latest firmware (being Android Lollipop 5.1.1) and the second URL to get the latest firmware image file. Unzipped both into my Windows 10 based laptop, installed the USB Burner utility v 2.0.9, watch the short video on Youtube, plugin the box via USB cable, run the installer and attempt upload, except it would not connect between the NEO X8H and the laptop USB Burner utility, I messed around for a couple hours, I even looked for later version of utility 2.1.7, still no good, replicated the whole process on another laptop, still refuses to connect, checking the Windows Devices, I eventually clicked that it showing two 2.4GHz mouse drivers, then I eventually realised, I still had the wireless mouse and keyboard receivers plugged into the NEO's USB ports, removed the two receivers, started the process again, this time it connected fine, the Amlogic USB Burner utility didnt like any other devices plugged into the NEO, except for the power cable and OTG USB.
Started the download, fails at 98%, tried again, still fails, and noting that it exits the USB program, try it all again on another Windows 10 laptop, fails again at 98% download. I thinking is it the NEO at fault or not, so I decided to uninstall the USB Burner utility 2.1.7 and go back to the 2.0.9 version as referenced and supplied in the Minix forum URL's, bingo! now it connects and uploads to the NEO successfully, disconnect USB cable and power off and go plug the NEO into a TV and it is working, with Lollipop 5.1.1. Tested it all working fine, still has XBMC player Next step is to uninstall XBMC and download and install KODI player. I very impressed with the guys on the Minix forum, simple plain instructions and procedure to follow, hard to understand how some users screwed the upgrade up, but they do. You would think that the later version of USB Burner utility would work, but no, it has some fault with respect to the NEO X8H+ during the flashing. Use the v 2.0.9 unless otherwise stated by the Minix forum.
the minixforum firmware releases
Next I wanted to upgrade my Minix NEO X8H Plus Media Center, that is Minix the hardware company, not Minix the POSIX/UNIX O/S. Anyway, this Minix box came with Android 4.4 and XBMC Media Center application, for watching movies, interfacing with PVR apps, TV, Music, player and manager. XBMC became Kodi, which is well known in Linux world as a media player and content manager. I bought this little box a few years ago, to interface with the TV and watch internet TV, but in recent years those TVs replaced by Smart TV's, so I can do all that internet TV stuff much faster and easier from the LG Smart TV's, so the little Minix box started collecting dust.
Recently, I was curious to see if others had put these Media Centers to other uses and a bit of searching yielded many results, people use these little boxes as game consoles, by replacing the O/S with other customised Linux based spins onto these boxes as retro Game consoles, or combination media center and games consoles, but if I wanted a games console, I'd just go buy a Xbox or Playstation. Anyway, coming back to the Minix box, I found some forums and in particular the Minux forum and people were upgrading them to get the latest functionality of Kodi, so I thought I have nothing to lose but upgrade the box to Android Lollipop 5.1.1 from the original KitKat 4.4 and put later Kodi player on.
Upgrading the Minix NEO X8H Plus unit was damned easy, the forum spelled out the procedure in half a page, two URLS, one for the USB burner utility, which is used to upload the latest firmware (being Android Lollipop 5.1.1) and the second URL to get the latest firmware image file. Unzipped both into my Windows 10 based laptop, installed the USB Burner utility v 2.0.9, watch the short video on Youtube, plugin the box via USB cable, run the installer and attempt upload, except it would not connect between the NEO X8H and the laptop USB Burner utility, I messed around for a couple hours, I even looked for later version of utility 2.1.7, still no good, replicated the whole process on another laptop, still refuses to connect, checking the Windows Devices, I eventually clicked that it showing two 2.4GHz mouse drivers, then I eventually realised, I still had the wireless mouse and keyboard receivers plugged into the NEO's USB ports, removed the two receivers, started the process again, this time it connected fine, the Amlogic USB Burner utility didnt like any other devices plugged into the NEO, except for the power cable and OTG USB.
Started the download, fails at 98%, tried again, still fails, and noting that it exits the USB program, try it all again on another Windows 10 laptop, fails again at 98% download. I thinking is it the NEO at fault or not, so I decided to uninstall the USB Burner utility 2.1.7 and go back to the 2.0.9 version as referenced and supplied in the Minix forum URL's, bingo! now it connects and uploads to the NEO successfully, disconnect USB cable and power off and go plug the NEO into a TV and it is working, with Lollipop 5.1.1. Tested it all working fine, still has XBMC player Next step is to uninstall XBMC and download and install KODI player. I very impressed with the guys on the Minix forum, simple plain instructions and procedure to follow, hard to understand how some users screwed the upgrade up, but they do. You would think that the later version of USB Burner utility would work, but no, it has some fault with respect to the NEO X8H+ during the flashing. Use the v 2.0.9 unless otherwise stated by the Minix forum.
the minixforum firmware releases
Labels:
firmware upgrade,
media center,
Minix,
NEO X8H Plus,
tv
Sunday, May 3, 2020
DMR activity
I had not played with my DMR radios and hotspots for almost 2 years, just too busy to update them again, reprogramming codeplugs to keep up with changes in the local VK networks. Having to work from home, I can get to do some tinkering while not having to travel each day, it was only from monitoring local FM repeaters whilst working at home, that I heard a few other people were configuring and testing their DMR radios and hotspots, so I got my gear out of the cupboard and turned it all, did some searches to check on local talkgroups, firmware and software updates, etc.
1st stop, was my SharkRF OpenSPOT1 hotspot, upgraded the firmware from 1.1-0117 to 1.1-0141 made some configuration changes and it was soon ready.
2nd stop my JumboSpot MMDVM hotspot, first upgrade the Pi-Star dashboard from 20180502 to 20200503, I do need to do the Pi-Star firmware as it currently a few years behind on 3.4.12, firstly will go to 3.4.17 and then try building another SD card so I can test ver 4 of Pi-Star.
3rd stop was my Radiodity GD-77 it had Firmware 3.00.06, DSP HRC6000 v1.2 and was using CPS 3.1.1. as I realised later it was the wrong CPS, anyway, upgraded to Firmware 4.2.8 (2019-12-4) and CPS 3.1.9 , first exporting the Contacts and Channels to .csv so that I could import under the new CPS, this all went fine, new codeplug created, loaded, all looked fine, except after a while I realised it not decoding any received stations, however, analogue FM worked fine. Did some reading of discussions, to see how to clear memory, tried that, did not help, only showed that it wiped new codeplug, but old codeplug was still in memory. Forums gave clue that memory mapping not the same, but overlapped from 3.x to 4.x and suggested need to properly clear memory, by reverting to old firmware v 2.63, because v3.06 had bug of wiping internal TX power settings, if I was to do the Memory Reset. I had all versions of firmware from 3.0.6 and above, but I could not trust that if I loaded another version ie. 3.1.6, 3.1.8, 3.2.1 or 3.2.2 that they would be capable of clearing memory without the TX power bug seen in 3.0.6. (in other words, I did not want to brick my TX power internal setup)
The forums suggested safest and guaranteed method was rollback to firmware v2.63, which I did and I then was able to clear the memory of my original codeplug. The older v2.6.3 firmware actually does clear everything in memory, it displays an extra message I think it said Factory Initiliase. Then I upgraded firmware to 4.2.8, loaded my new codeplug created under CPS 3.1.9 and now it all works perfectly.
Last, was upgrade my TYT MD-380, it had MCU F/W D0003.020 and CPS v01.27 HW 1.00 after some reading of forums I see there are later version of the MD-380 which they refer to as the new vocoder, so my unit was the old vocoder which has the most recent firmware, so my issue here was I was using the wrong CPS, it should be 1.32 . I found you really need to have the correct matching CPS against the firmware version being used. I updated and save my existing codeplug using the correct CPS version 1.32 now this MD-380 doing the correct behaviour.
In summary, OpenSpot is on Brandmeister network, my MMDVM on the VK-DMR network (formerly DMR-MARC) and it looks like the operators of VKDMR have settled down to defined set of TG's instead of this constant changing of TG's every week trying to keep up with the whingers.
As far as Brandmeister is concerned, slowly discovering what TG's are there, seems to be a whole suite of different gateways operating in various multimode combinations for NXDN, P25, D-Star and YSF/WIRES-X and monitoring these gateway/reflectors I see lots of people experimenting, which is good. I even had a contact with VK2JDS on P25, using my DMR hheld via the VK3GWY multimode gateway.
Discovered there is a new DMR simplex, it is now 439.200 MHz TG99 and 145.650 TG99
The unfortunate discovery was some hotspot operators running their hotspots in totally wrong parts of the band, one was on 432.000 right on the edge EME section, (in fact they are in breach of their license) the other was on 432.125MHz smack in the weak signal SSB section of 70cm. Some people just got no idea of WTF they doing. They really need to read the WIA Bandplan.
1st stop, was my SharkRF OpenSPOT1 hotspot, upgraded the firmware from 1.1-0117 to 1.1-0141 made some configuration changes and it was soon ready.
2nd stop my JumboSpot MMDVM hotspot, first upgrade the Pi-Star dashboard from 20180502 to 20200503, I do need to do the Pi-Star firmware as it currently a few years behind on 3.4.12, firstly will go to 3.4.17 and then try building another SD card so I can test ver 4 of Pi-Star.
3rd stop was my Radiodity GD-77 it had Firmware 3.00.06, DSP HRC6000 v1.2 and was using CPS 3.1.1. as I realised later it was the wrong CPS, anyway, upgraded to Firmware 4.2.8 (2019-12-4) and CPS 3.1.9 , first exporting the Contacts and Channels to .csv so that I could import under the new CPS, this all went fine, new codeplug created, loaded, all looked fine, except after a while I realised it not decoding any received stations, however, analogue FM worked fine. Did some reading of discussions, to see how to clear memory, tried that, did not help, only showed that it wiped new codeplug, but old codeplug was still in memory. Forums gave clue that memory mapping not the same, but overlapped from 3.x to 4.x and suggested need to properly clear memory, by reverting to old firmware v 2.63, because v3.06 had bug of wiping internal TX power settings, if I was to do the Memory Reset. I had all versions of firmware from 3.0.6 and above, but I could not trust that if I loaded another version ie. 3.1.6, 3.1.8, 3.2.1 or 3.2.2 that they would be capable of clearing memory without the TX power bug seen in 3.0.6. (in other words, I did not want to brick my TX power internal setup)
The forums suggested safest and guaranteed method was rollback to firmware v2.63, which I did and I then was able to clear the memory of my original codeplug. The older v2.6.3 firmware actually does clear everything in memory, it displays an extra message I think it said Factory Initiliase. Then I upgraded firmware to 4.2.8, loaded my new codeplug created under CPS 3.1.9 and now it all works perfectly.
Last, was upgrade my TYT MD-380, it had MCU F/W D0003.020 and CPS v01.27 HW 1.00 after some reading of forums I see there are later version of the MD-380 which they refer to as the new vocoder, so my unit was the old vocoder which has the most recent firmware, so my issue here was I was using the wrong CPS, it should be 1.32 . I found you really need to have the correct matching CPS against the firmware version being used. I updated and save my existing codeplug using the correct CPS version 1.32 now this MD-380 doing the correct behaviour.
In summary, OpenSpot is on Brandmeister network, my MMDVM on the VK-DMR network (formerly DMR-MARC) and it looks like the operators of VKDMR have settled down to defined set of TG's instead of this constant changing of TG's every week trying to keep up with the whingers.
As far as Brandmeister is concerned, slowly discovering what TG's are there, seems to be a whole suite of different gateways operating in various multimode combinations for NXDN, P25, D-Star and YSF/WIRES-X and monitoring these gateway/reflectors I see lots of people experimenting, which is good. I even had a contact with VK2JDS on P25, using my DMR hheld via the VK3GWY multimode gateway.
Discovered there is a new DMR simplex, it is now 439.200 MHz TG99 and 145.650 TG99
The unfortunate discovery was some hotspot operators running their hotspots in totally wrong parts of the band, one was on 432.000 right on the edge EME section, (in fact they are in breach of their license) the other was on 432.125MHz smack in the weak signal SSB section of 70cm. Some people just got no idea of WTF they doing. They really need to read the WIA Bandplan.
WIA VHF UHF SHF Field Day Contests 2020
due to Covid19 isolation winding up at start of March, I decided not to go away for the JMFD contest, my local club still went, to Barrington Tops, I didnt think it be useful as a contest for UHF and above, as they were camping in a valley, but there were some excellent high spots 10 minutes drive from campsite. Keep that for a future contest. Also due to Covid shutdown the WIA AGM in Hobart postponed to May 2021. And the GippsTech Conference postponed until July 2021
I had some discussion with some other contesters about June FD contest, we thought to drive to northern NSW to work the VK4 microwavers, however, that was soon scrapped, as the Covid19 shutdown would prevent that, with no real idea on when we can get back to normal, so we set our eyes for November as the next VHF-UHF-SHF contest FD. The June contest will just have to be done from home this year, I think at this stage.
Dates for remainder of the year:
The Winter Contest is Sat/Sun 20th/21st June 2020,
The Spring Contest is Sat/Sun 28th/29th Nov 2020
November should have us back to normal as far as travelling interstate. It not too hot to go to VK4. I wondering if the VK5's planning any roadtrips, they might want to join us for some serious microwave contesting in VK4. Lots of good mountain tops for microwaving around VK4/VK2 border.
While I am at it, here are dates for next year :
The Summer Contest is Sat/Sun 16th/17th Jan 2021
The Winter Contest is Sat/Sun 26th/27th Jun 2021
The Spring Contest is Sat/Sun 27th/28th Nov 2021
http://www.wia.org.au/members/contests/vhfuhf/
I had some discussion with some other contesters about June FD contest, we thought to drive to northern NSW to work the VK4 microwavers, however, that was soon scrapped, as the Covid19 shutdown would prevent that, with no real idea on when we can get back to normal, so we set our eyes for November as the next VHF-UHF-SHF contest FD. The June contest will just have to be done from home this year, I think at this stage.
Dates for remainder of the year:
The Winter Contest is Sat/Sun 20th/21st June 2020,
The Spring Contest is Sat/Sun 28th/29th Nov 2020
November should have us back to normal as far as travelling interstate. It not too hot to go to VK4. I wondering if the VK5's planning any roadtrips, they might want to join us for some serious microwave contesting in VK4. Lots of good mountain tops for microwaving around VK4/VK2 border.
While I am at it, here are dates for next year :
The Summer Contest is Sat/Sun 16th/17th Jan 2021
The Winter Contest is Sat/Sun 26th/27th Jun 2021
The Spring Contest is Sat/Sun 27th/28th Nov 2021
http://www.wia.org.au/members/contests/vhfuhf/
Labels:
1.2GHz,
10.368.100,
10ghz,
1296.150,
144.150 432.150,
2.4GHz,
3.4Ghz,
3398.100,
5.7GHz,
amateur radio,
field day contest,
microwave,
portable,
shf,
ssb,
uhf,
vhf,
wia
Location:
Australia
Subscribe to:
Posts (Atom)