Author Archives: John Cole

DMR: Update to the AnyTone radios

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 

DMR Repeater and Antenna Installation Status

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

 

DMR: Pi-Star – How to upgrade vn4.1 rc from earlier versions

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

QSL Report: Aug 2019

New DXCC this month
Trinidad & Tobago (9Y) 6m, Digital; Portugal (CT) 6m; Canary Islands (EA8) 6m; Ireland (EI) 6m; Isle of Man (GD) 6m, Digital; Scotland (GM) 6m; Wales (GW) 6m; Dominican Republic (HI) 6m, Digital; Colombia (HK) 6m, Digital; Sardinia (IS0) 6m, Digital; Puerto Rico (KP4) 6m; Belgium (ON) 6m; Greenland (OX) Digital; Brazil (PY) 6m; Costa Rica (TI) 6m; Ukraine (UR) 6m; Mexico (XE) 6m; New Zealand (ZL) 20m, Digital.

New WAS this month
CO, 80m Digital; IN, 40m Digital; KY, 80m Digital; MD, 40m Digital, 80m Digital; MT, 40m Digital; NC, 15m Digital, 80m Digital; ND, 80m Digital; NH, 40m Digital; NJ, 80m Digital; OH, 80m Digital; NV, 6m Digital; OR, 40m Phone; SC, 80m Digital; TX, 80m Digital; VA, 80m Digital; WV, 40m Digital. Need NM, SD, and WY on 10m for 5BWAS.

New VUCC this month
DL99; DM26; EJ79; EK09; EL08; FJ34; FJ92; FK49; FK58; FK68; FK90; IL18; IM68; IN50; IO53; IO72; IO74; IO75; IO84; JM49; JM76; JN55; JN61; JO21; KN77

New WAZ this month
Z6, Digital; Z11, 6m; Z16, 6m; Z32, 20m (Digital); Z33, 6m, 20m (Digital); Z40, 17m (Digital)

180 (+1) QSLs have been received from our 2012 Field Day activity.
192 (+0) QSLs have been received from our 2013 Field Day activity.
267 (+0) QSLs have been received from our 2014 Field Day activity.
299 (+2) QSLs have been received from our 2015 Field Day activity.
171 (+0) QSLs have been received from our 2016 Field Day activity.
281 (+1) QSLs have been received from our 2017 Field Day activity.
469 (+0) QSLs have been received from our 2018 Field Day activity.
214 (+214) QSLs have been received from our 2019 Field Day activity.

Ed N4II

 

Field Day 2019: Visit by Commissioner Weinroth

On June 22 2019, Commissioner Weinroth visited with members of the Boca Raton Amateur Radio Association at their annual Amateur Radio “Field Day” at the West Delray Regional Park as part of the national Amateur Radio Field Day exercise. Field Day is a showcase for how amateur radio (also known has ham radio) works reliably under any conditions from almost any location to create an independent communications network. Since 1933, ham radio operators across North America have established temporary ham radio stations in public locations during Field Day to showcase the science and skill of Amateur Radio.

Jerry.Z W4BFL, Bruce KO4XL, Commissioner Weinroth, Michael Siegel W2RT

DMR: Pi-Star Firmware upgrade for mmdvm HS hat flash by 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

DMR: Adjusting the offset by Al AF4FA

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: Fix BER procedure by Al AF4FA

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 Rules by Al AF4FA

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

DMR: Diagnosing system errors during bootup by Al AF4FA

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