Bud Talbot W0RMT

An important question to consider when building a pi-star based hotspot is what version of raspberry pi to use. You have three basic form factors to choose from: the zero, A+, and B+. The pi-zero is the smallest of these three, followed by the A+, and then the B+. The latest versions are the pi-zero W (or WH, which just has the header soldered on), the pi-3 A+, and the pi-3 B+. Other important factors to consider besides size are power consumption (very important for portable setups), boot time, wireless connection strength, and time required to switch configurations.

pi Specs

First let’s look at some published specifications for each of these models. Below is a nice chart from http://socialcompare.com/en/comparison/raspberrypi-models-comparison

From this chart, you can see that both the pi-3 A+ and pi-3 B+ have quad core processors clocked at 1.4 GHz. The difference between these two computers in terms of system resources is the RAM: the pi3 A+ has 512 MB while the pi-3 B+ has 1 GB. Note that the A+ form factor also lacks the RJ45 ethernet port, and only has 1 USB port. Neither of these is really a huge limitation for a hotspot in my opinion. That said, I do like to connect my pi-3 B+ based hotspots directly to the ethernet when available. The pi-zero is much smaller, but also has only a single core processor clocked at 1 GHz with 512 MB or RAM. So we can expect it to be slower in terms of performing operations. But for that tradeoff, you should see significantly less power consumption. Another important difference is in the WiFi: the A+ and B+ support both 2.4 GHz and 5 GHz 802.11 b/g/n/ac protocols, while the pi-zero only supports 802.11n over 2.4 GHz. This is likely to be an important factor as well.

Testing Procedure

In order to look more deeply at power consumption, I set up a test where I compared the three different raspberry pi options (zero, A+, and B+) using the same mmdvm hat (an N5BOC simplex board) and the same instance of pi-star (v 4.0 RC3) installed on a micro SD card (Patriot class 10 16 GB), and using the same power supply.

I then measured voltage (V) and current (I) over time using a small, inline USB meter (the UM25C). One nice thing about the UMC is that it interfaces with a PC over bluetooth so that you can record V and I versus t and view a graph and output data on the PC. This is a screenshot of testing for the pi-zero:

For each of the raspberry pi models tested, I ran three trials where I booted the pi and let it run for 15 minutes. I set the pi-star image up for D-STAR, and used the voice announcement as my “ready indicator for boot time.” I recorded the following parameters:

• Boot time
• 15 minute capacity used (in mAh)
• 15 minute energy used (in mWh)
• steady state voltage and current
• pi load averages at 15 minutes (1’, 5’ and 15’ loads- see this linkif you’re not familiar with these metrics. Remember the pi-zero has a single core while the A+ and B+ have 4 cores)
• Temperature (open case) after 15 minutes. Note that future testing should probably be in closed case which is more typical of operation. But that also introduces many more variables for each form factor (e.g. air space in case, ventilation in each case, etc).
• Wifi signal strength (in dBm – see this linkif you’re not familiar with this measure). I measured this as signal strength received by my Ubiquiti networks access point, as read through the Unifi interface. For VoIP protocols, we really need at least -67 dBm. A lower value might work in some situations, but we’d like to see this greater than -67.

Results

Conclusion

So what’s the conclusion? First, let’s look at the data to identify some notable differences.

• Boot time: the pi-zero is about 20 s slower than the pi-3 A+ and B+
• Power consumption: the pi-zero uses the least power, but the A+ doesn’t use much more. The B+ is a hog by comparison.
• Maximum current on boot: again, the B+ has the largest, but it is still under 1 A. This surprised me, as I expected maximum current draw to be greater.
• Operating temperature: the A+ has the clear edge here. It’s not working as hard as the pi-zero (reference the load averages) and it’s larger board may dissipate heat better.
• Wifi signal strength: the zero really lags in this metric. The A+ and B+ have a 10x stronger wifi signal. This is a big deal.

Bottom line: I think the pi-3 A+ is probably the best in terms of boot time, low energy consumption, operating temperature, and wifi signal strength. And in terms of form factor, it’s not much larger than a pi-zero. I think that once we see some good case options for A+ based hotspots, we’ll notice a proliferation of ham hotspots built on the pi-3 A+. I know I’ll be migrating mine over to the pi-3 A+ from the pi-zero’s. I do think the pi-3 B+ board still has great utility in situations where power consumption is not an issue, like on the desktop in the shack where you are likely plugged into mains power and might want to connect to the network via ethernet.

Thanks for reading.

Bud

Here are the instructions for applying the vocoder update to the AnyTone radios.

There is a new Firmware update posted for the AnyTone 878 named vn 1.14. within this update there is an update for the Baseband IC 3258 chip. This update also applies to the AnyTone 868 but has not been published on the 868 update site. The update applies changes to the vocoder and hopefully fixes some issues with coding and decoding of the digital signals. In order to get the update go to the following link CLICK HERE

If you have an 868 only do the baseband update from this file.The rest of the updates do not apply to the 868. You have to unzip the file and save it somewhere on your computer. Go to the baseband update folder and read and follow the instructions carefully to apply the update to the chip.

73
Al AF4FA 

Summary: The new BRARA DMR Repeater and UHF Antenna were installed on Wednesday, July 31, and is operational for local communications on 442.875 MHz +5 MHz Offset (previous UHF repeater frequencies) with Color Code 1 (CC-1), Time Slot 2 (TS-2), Talk Group 311037 (TG-311037). Connection to Brandmeister is still pending (non-operational).

Details: On Tuesday, June 30, the Motorola SLR5700 DMR Repeater was programmed by Jerry Zaza. The repeater is Brandmeister repeat number 311037 and the local talk group was programed to be 311037. He tested local communication between two handhelds on TS-2 TG-311037, tested the connection to Brandmeister with the Ethernet connection, made sure the repeater would work locally even without an Ethernet connection, and made sure the repeater was broadcasting an analog CW ID every 10 minutes. After testing, which required a low power setting, he set the power setting back to maximum. Robert Eng picked up the DMR repeater and the Ethernet Microwave Antenna from Jerry for installation the next day.

On Wednesday, July 31, at 9:00 AM, Art Lewis, Gerry Gawaldo, and Robert Eng met at the BRARA shack and picked up the new UHF 4-element folded dipole antenna and transported it to the repeater site.

On Wednesday, July 31, at 10:00 AM, the team of Art Lewis, Lewis Lehman, Gerry Gawaldo, Grant Baron, Pablo Solsona, and Robert Eng met at the repeater site at the One Park Place building at the northwest corner of Yamato Road and I-95. The following was performed:

1. The new UHF antenna, tools, and the Microwave antenna were lifted by rope to the roof (top level) of the building. They had to be roped up because it was impossible to bring them up the vertical ladder which leads up to the roof.

2. The old UHF repeater antenna was removed. The mounting nuts were relatively easy to remove (ie they were not frozen).

3. The new UHF antenna was installed in same place as the old antenna using the existing hardware. SWR of new antenna was checked with a Rig Expert AA-600 Antenna Analyzer. SWR was around 1.2. The new antenna was connected to the existing coax cable. The new antenna has a male N connector and the existing cable had a female N connector. Connection was sealed with black tape.

4. The existing Ethernet cable was identified and tested with an Ethernet Cable tester. All 4 pairs and the shield of the cable tested OK.

5. Internet Microwave Antenna was mounted on the bottom of the UHF antenna mask slightly above the edge of the wall around the roof. Ethernet cable was attached. Antenna was leveled and pointed towards FAU.

6. Old UHF antenna and tools were lowered from roof using rope.

7. DMR Repeater was installed in repeater rack. Repeater transmit and receiver ports were hooked to duplexer. The transmit port were both N connectors but the receiver port required a female N to male BNC adapter (repeater receiver port is a female BNC).

8. Ethernet cable from Microwave Antenna was hooked to POE power supply, then cabled to an Ethernet Switch. The LAN1 port of the repeater was also connected to the Ethernet Switch.

9. Repeater was powered on. Gerry Gawaldo had a DMR handheld programmed for CC-1, TS-2, Talk Groups (TG) 1, 2, 9, and 311037. Found that Talk Groups 1, 2, 311037 made the repeater respond (transmit LEDs on front panel of repeater lit) but TG-9 had no response. Do not test actual voice communication because we only had one DMR radio.

Sometime on Wednesday afternoon, it appeared the repeater stopped working. Robert Eng could not get his CS800D at home to handshake with the repeater (getting Call Failed message) and Gerry Gawaldo could not longer contact the repeater with the same radio he used when we tested the repeater after installation.

On Thursday, August 1, at 11:00 AM, Art Lewis, Lewis Lehman, and Robert Eng went back to the repeater site to check the DMR repeater. The red alarm LED was lit, and it obviously had shutdown. Added a right angle adapter to the top of the repeater rack to relieve strain on coax going to antenna. Measured transmit power of DMR repeater – was about 50 watts when keyed up. Measured SWR of antenna plus coax (where coax connects to duplexer) and SWR was 1.3. Tested communication between two DMR handhelds on TG 311037 both near the repeater and outside in parking lot and voice communication works OK.

The Internet connection portion at the repeater site should be complete (other than the antenna aiming may need to be refined). The FAU portion of the Internet connection still needs to be completed in order for the connection to Brandmeister to work.

If I forgot or misstated something, please feel free to correct me. As one gets older, the memory starts to fail.

A million thanks to everyone that helped with this effort to get the DMR repeater up and running. Greatly appreciate your time, effort, and expertise.

73

Robert Eng W1ENG

How to upgrade to the latest vn4.1 rc from earlier versions of Pi-Star. The new version is designed to work on all versions of the RPI boards from a Pi zero up to the latest Pi 4 boards. It became necessary due to the release version of Linux changing and the new features of the new Pi 4 boards.

First you must backup your current pistar configuration. In order to then upgrade you will have to download from the pistar website the latest version ( beta version as of now ) of the software. You will then have to reformat an SD card and then burn the image to the SD card. After that is done copy the backed up configuration zip file to the root directory of the SD card. At this point you can place the SD card into your hotspot and boot it up. It will take several minutes for the hotspot to complete the upgrade and then you will be able to log into it. If you had changed the password from raspberry to something else it will be returned to raspberry as that is one of a few fields that is not saved in a backup. At this point do an SSH login in and do a sudo pistar-upgrade to load that latest upgrades. After that is done do a sudo pistar-update to get the latest updates to the Linux and any pistar binaries that have been updated since the image file was created. Now you can look at the fields on the admin page and the configuration page and make sure any fields you changed but were not backed up are made correct.

Al AF4FA

Revised: 23-July 2019

If you have a different modem board you need to adjust the commands to those for your particular board using the list at the bottom.

– open your pi-star admin dashboard in a web browser
– go to configuration
– go to expert
– go to SSH-Access
– log on (user pi-star + your password)
– type “sudo service mmdvmhost stop” press enter
– type “sudo pistar-mmdvmhshatflash hs_hat” press enter
– confirm by pressing any key (last chance to back out by pressing CTRL-C here)
– wait till you get the message that flashing is complete,then press any key to reboot
– open your pi-star dashboard in a web browser again
– go to configuration and scroll down and

See if the Modem connected. If yes you are done. If no continue.

– go to expert
– go to SSH-Access
– log on (user pi-star + your password)
– type “sudo service mmdvmhost start” press enter
– type “exit” press enter
– done
– If Modem still does not connect then
– open your pi-star dashboard in a web browser
– click on Admin
– go to configuration and at the bottom click on configure wifi and if the ssid shown is correct click on save(and connect) and exit.

The modem should connect and the IP address should show on the screen and the status should show interface is up in green.

You have completed the upgrade.

ZUMspot board connected to GPIO:
sudo pistar-zumspotflash rpi

MMDVM_HS_Hat board with 14.7456 MHz TCXO connected to GPIO:
sudo pistar-mmdvmhshatflash hs_hat

MMDVM_HS_Hat board with 12.288 MHz TCXO connected to GPIO:
sudo pistar-mmdvmhshatflash hs_hat-12mhz

MMDVM_HS_DUAL_Hat board with 14.7456 TCXO connected to GPIO:
sudo pistar-mmdvmhshatflash hs_dual_hat

MMDVM_HS_DUAL_Hat board with 12.288 TCXO connected to GPIO:
sudo pistar-mmdvmhshatflash hs_dual_hat-12mhz

Nano Hat board connected to GPIO:
sudo pistar-vyehsflash nano_hs

HS_DUAL_HAT (VR2VYE) connected to GPIO:
pistar-vyehsflash hs_dual_hat

NanoDV NPi board:
sudo pistar-nanodvflash pi

NanoDV USB board:
sudo pistar-nanodvflash usb

BD7KLE/BG3MDO devices:
sudo pistar-mdoflash

ZUMspot duplex board connected to GPIO:
sudo pistar-zumspotflash rpi_duplex

ZUMspot USB key:
sudo pistar-zumspotflash usb

USB-connected Libre Modem:
sudo pistar-zumspotflash libre

Most of the boards lately have required adjusting the offset to function properly on DMR. Many boards are shipped with a sticker on the bottom with the required offset.

These are usually pretty close. There is however a way to get this more exact and specific to your radio. Luckily there is a utility built in to Pi Star that enables you to tune your offset.

MMDVMcal
All it requires is pen and paper, a calculator and a little time.

Step one is to gain ssh access to your Pi. The easiest way to do this is go to “Configuration” then click “Expert” then “SSH Access” and log in with pistar and your password.

First, set your radio to 433.000mHz Talk Group 1 and Color Code 1 TS 1.

Next, use the command in SSH to start mmdvmcal “sudo pistar-mmdvmcal” then press “b” to start the BER tuning program.

1.Press the PTT on your radio for about 1 second. Then unkey.
2.If no BER response or a high response press the “F” key to raise the frequency and repeat step 1 until you get the smallest BER you can.

If you get to more than 1.5kc from the starting frequency without seeing a BER response or if the BER keeps increasing press “Q” and start the program over and press “f” instead of “F” and repeat steps 1 and 2 lowering the frequency until you get the smallest BER you can achieve.

At this point you can change the frequency step to a lower increment by using the “Z’ key and entering a lower step (50 or 25 or 10) and go back to step 1 to see how much lower you can get by using the “F” and/or “f” keys.

When you are satisfied with the BER then do the following.

However far off you are from the starting frequency of 433mHz is what your RXOffset should be set to plus or minus.

Most of the boards lately have required adjusting the offset to function properly on DMR. Many boards are shipped with a sticker on the bottom with the required offset.

These are usually pretty close. There is however a way to get this more exact and specific to your radio. Luckily there is a utility built in to Pi Star that enables you to tune your offset.

MMDVMcal
All it requires is pen and paper, a calculator and a little time.

Step one is to gain ssh access to your Pi. The easiest way to do this is go to “Configuration” then click “Expert” then “SSH Access” and log in with pistar and your password.

First, set your radio to 433.000mHz Talk Group 1 and Color Code 1 TS 1.

Next, use the command in SSH to start mmdvmcal “sudo pistar-mmdvmcal” then press “b” to start the BER tuning program.

1.Press the PTT on your radio for about 1 second. Then unkey.
2.If no BER response or a high response press the “F” key to raise the frequency and repeat step 1 until you get the smallest BER you can.

If you get to more than 1.5kc from the starting frequency without seeing a BER response or if the BER keeps increasing press “Q” and start the program over and press “f” instead of “F” and repeat steps 1 and 2 lowering the frequency until you get the smallest BER you can achieve.

At this point you can change the frequency step to a lower increment by using the “Z’ key and entering a lower step (50 or 25 or 10) and go back to step 1 to see how much lower you can get by using the “F” and/or “f” keys.

When you are satisfied with the BER then do the following.

However far off you are from the starting frequency of 433mHz is what your RXOffset should be set to plus or minus.

DMR Gateway will only pass traffic to the different networks if it’s referenced in a rewrite rule in the .ini file.

TGRewrite

TGRewrite allows you to translate one talk group ID to another, and to alter the time slot.

TGRewrite can also be used to route a talk group and slot combination to a particular network.

‘from’ applies to DMR frames entering the Gateway via MMDVMHost (RF), and ‘to’ is where they are routed on the network side (Net). The rules apply to DMR frames traversing the gateway in both directions.

Syntax
TGRewrite=fromSlot,fromTG,toSlot,toTG,range

Examples
The rule below will translate a group call to talk group talk group 8 to talk group 9 on DMR Network 1.

[DMR Network 1]
# Reflector TG on to slot 2 TG8
TGRewrite=2,8,2,9,1

The rules below will route a group call to 9990 on time slot 1 to DMR Network 1, and a group call to 9990 on time slot 2 to DMR Network 2.

[DMR Network 1]
# Echo on slot 1 TG9990
TGRewrite=1,9990,2,9990,1
[DMR Network 2]
# Echo on slot 2 TG9990
TGRewrite=2,9990,2,9990,1

PCRewrite

This is almost identical to the TGRewrite except it only operates on private calls. PCRewrite can be used to add a prefix on a private call to a reflector to ‘steer’ them to a particular network. The prefix will then be removed before being routed to the DMR network. ~~The rules apply to DMR frames traversing the gateway in both directions.~~~ This rule only works on DMR frames apassing from the RF side to the network.

Typically used to remap reflector control calls to a different local range to avoid clashes, and for permitting GPS position reports and private calls to a particular network.

Syntax
PCRewrite=fromSlot,fromId,toSlot,toId,range

Examples
The rules below will route any private calls on time slot 2 in the range 94000 – 95000 to 4000 –
5000 on DMR Network 1, and the range 84000 – 85000 to 4000 – 5000 on DMR Network 2.

[DMR Network 1]
# Reflector control command slot 2 94000->4000 to 95000->5000
PCRewrite=2,94000,2,4000,1001

[DMR Network 2]
# Reflector control command slot 2 84000->4000 to 85000->5000
PCRewrite=2,84000,2,4000,1001

SrcRewrite

SrcRewrite will rewrite the source/from Talk Group ID to another ID.

Syntax
SrcRewrite=fromSlot,fromId,toSlot,toTG,range

Examples
The rule below will rewrite calls from 4000-5000 on DMR Network 1, to talk group 9 on slot 2. This is useful for ensuring reflector announcements are heard on talk group 9. This rule only works on DMR frames passing from the network side to the RF side.

[DMR Network 1]
# Reflector status returns
SrcRewrite=2,4000,2,9,1001

TypeRewrite

TypeRewrite maps a group call to a private call. This rule only works on DMR frames passing from the RF side to the network side.

Syntax
TypeRewrite==fromSlot,fromId,toSlot,toId

Example
The rules below translate a group call to 9990 on slot 1, to a private call on DMR Network 1. The SrcRewrite rule then allows the reply to traverse the gateway. This could be used for converting Brandmeister’s private call echo service to a group call method like DMR+, to make the usage more uniform across the networks.

[DMR Network 1]
# Echo on RF slot 1 TG9990 to network slot 1 9990
TypeRewrite=1,9990,1,9990
SrcRewrite=1,9990,1,9990,1

PassAllTG

Passes all talk groups without specific matching rules, and can only be used on a single DMR network. The rules apply to DMR frames traversing the gateway in both directions.

Syntax
PassAllTG=Slot

Example
The rules below allow group calls to traverse from DMR network 2 to either time slot on the RF side.

[DMR Network 2]
# Pass all of the other talk group traffic on slot 1 and slot 2
PassAllTG=1
PassAllTG=2

PassAllPC

Passes all private calls without specific rules, and can only be used on a single DMR network. The rules apply to DMR frames traversing the gateway in both directions.

Syntax
PassAllPC=Slot

Example
The rules below allow private calls to traverse from DMR network 2 to either time slot on the RF side.

[DMR Network 2]
# Pass all of the other private traffic on slot 1 and slot 2
PassAllPC=1
PassAllPC=2

SSH in to the PI-STAR system and use these 2 commands to display all the kernel messages from the booting up of the system and if there is a file system error displayed at the end of dmesg then run the fsck utility to correct it. Dmesg is useful in determining and aiding in the fixing of any errors that occurred during the bootup.

sudo dmesg (Display message or driver message) is a command which will show Kernel ring buffers. These messages contain valuable information about device drivers loaded into the kernel at the time of booting as well as when we connect a hardware device to the system on the fly. In other words dmesg will give us details about hardware drivers connected to, disconnected from a machine and any errors when the hardware driver is loaded into the kernel. These messages are helpful in diagnosing or debugging hardware and device driver issues.

The above command will give us all the hardware drivers loaded in to the kernel,their status of success or failed and even the error message as to why they failed. If there is a file system error noted at the end of the list the run fsck. sudo fsck The system utility fsck (file system consistency check) is a tool for checking the consistency of a file system in Unix and Unix-like operating systems and fixing the error(s) if possible.

The exit code returned by fsck is a unique number representing the sum of the following condition values:

0 – No errors
1 – Filesystem errors corrected
2 – System should be rebooted
4 – Filesystem errors left uncorrected
8 – Operational error
16 – Usage or syntax error
32 – Fsck canceled by user request
128 – Shared-library error

A new configuration pushed is a fairly substantial change to the way the DMR ID is handled by the Pi-Star Config page.

In short – the reasoning behind this is that the way DMR IDs are handled by the networks needs to be understood to get the best out of them.

Brand Meister:

This network uses either your bare CCS7/DMR ID (7 digits) *OR* an extended ID, your 7 digit ID, with a 2 digit suffix (between 01 and 99).

Specifically BM does *NOT* accept 8 digit IDs. These have worked in the past, but BM sees 8 digits as a base ID, technically speaking BM DMR IDs are 24 bits, when expressed as an unsigned integer (programming term for a positive only number) this provides a range of IDs from 0 (0000000) to 16777215.

DMR Plus:

Information here is a little sketchy, but it seems that DMR Plus supports CCS7 / DMR ID (7 digits) on all of their masters, and 8 digit (extended) DMR IDs on at least some of their masters (your 7 digit CCS7 ID, plus 1 digit, 1-9).

TGIF:

I believe that they support 7 or 9 digits in a similar way to BM. (I’m going to reach out to the admins there today to make sure).

So why the change – well it’s been on the cards for a while to better support extended IDs when using DMRGateway, AND specifically 8 digit IDs to NOT work on BrandMeister when using hotspot security, so this change helps enforce the use of 7 or 9 digit IDs but not 8 digits on BM.