Cannot connect to Brandmeister network

Help with DMR issues
G4TVP
Posts: 26
Joined: Mon Feb 03, 2020 11:30 pm

Re: Cannot connect to Brandmeister network

Post by G4TVP » Sat Jul 25, 2020 5:02 pm

Hi Brian, I've tried using the configuration you sent me, and I still get the same result, which is :
E: 2020-07-25 16:52:44.137 Unable to read the firmware version after six attempts
Monitoring the frequency with my analog handie, I can hear an open carrier on 438.6375.

Just to be sure, I've tried mounting the MMDVM on a Pi-Zero I had here already and I get the same result. I think we can say this board is not working?

Can this boards (MMDVM) be purchased still. I can see Zumspots and OpenSpots, but they are expensive.

G8SEZ
Posts: 216
Joined: Fri Apr 13, 2018 8:26 pm

Re: Cannot connect to Brandmeister network

Post by G8SEZ » Sat Jul 25, 2020 8:27 pm

Sounds like there is something not right, but fault-finding is not too easy

You could look at this link:

https://www.ebay.co.uk/itm/Hot-Jumbospo ... Swr1Fe-8y-

which offers different costs depending on which parts you want.

There are plenty of others, they usually arrive more rapidly than advertised.
Last edited by G8SEZ on Sat Jul 25, 2020 8:30 pm, edited 1 time in total.
--

Brian G8SEZ

KE7FNS
Posts: 943
Joined: Wed Apr 17, 2019 11:11 pm

Re: Cannot connect to Brandmeister network

Post by KE7FNS » Sat Jul 25, 2020 8:29 pm

G4TVP wrote:
Sat Jul 25, 2020 9:43 am
I have downloaded the latest version of Pi-Star this week (4.1.2) on the recommendation of Brian. All I did was put into the basic config my DMR id, selected BM UK and entered my self-care password.
If that is all you did then you didn't properly set the modem configuration and that would explain why it fails to communicate with the modem. You should of been given a warning about needing to change it.
G4TVP wrote:
Sat Jul 25, 2020 9:43 am
The SD card Iam using is a Kingston SDHC/16gb (class 10). We have been using these for about a year, without issue.
According to that list users have submitted issues with some Kingston SDHC/16gb. You really should get more detailed info on which specific part number you are using and make sure.

Just because you think there are no issues doesn't mean there aren't any issues using it with a RPi. I have a Patriot 32 gig card and when I use it everything appears to work, but every time a file is written a bit of it gets corrupted with garbage. This really causes havok during an OS update as many files are written. The longer this goes on the worse things get. That card works fine in other devices just not a RPi. Other smaller sized Patriot cards don't report the same issue.
G4TVP wrote:
Sat Jul 25, 2020 9:43 am
I really don't want to change anything on the Expert configuration, but the stock firmware just leaves the DMR id of 1234567 in there, so had no choice but to change that, otherwise I can see the script would fail.
In what area (expert menu choice and section) are you referring to where it leaves it as 1234567?

It sounds to me like you are not "applying changes" correctly on the basic configuration page after you make changes in each section.
G4TVP wrote:
Sat Jul 25, 2020 9:43 am
My question would be, are the errors I am seeing (see my last post), indicative of a hardware failure or software configuration? I've asked a couple of times for the complete config, so I can try that, but to no avail.
You haven't provided enough details to make that determination. I doubt it hardware failure because you said it worked fine on DStar before you started messing around with DMR. If it was a hardware issue then both DStar and DMR wouldn't work.

What modem hat do you have, and what configuration have you selected?

What is the sequence of the modem LED lights when you apply power?
If someones previous actions are any indication of their future actions, then I predict the deletion and removal of access will happen at any moment. 7-11-2020.

"07/13/20 This Website Has Been Taken Down" ... again :lol:

AF6VN
Posts: 466
Joined: Fri Jul 20, 2018 1:15 am

Re: Cannot connect to Brandmeister network

Post by AF6VN » Sun Jul 26, 2020 4:05 pm

KE7FNS wrote:
Sat Jul 25, 2020 8:29 pm
According to that list users have submitted issues with some Kingston SDHC/16gb. You really should get more detailed info on which specific part number you are using and make sure.

Just because you think there are no issues doesn't mean there aren't any issues using it with a RPi. I have a Patriot 32 gig card and when I use it everything appears to work, but every time a file is written a bit of it gets corrupted with garbage. This really causes havok during an OS update as many files are written. The longer this goes on the worse things get. That card works fine in other devices just not a RPi. Other smaller sized Patriot cards don't report the same issue.
As I recall, Kingston does not manufacture cards -- they buy job lots from lowest bidder sources and stamp their name on the cards. Two identically labeled Kingston cards could be widely different with regards to internal circuitry.

And "Class 10" is not a guarantee that a card is suited for use with a journalling file system (which is what Linux normally uses). The Class 10 specification is based upon writing a single media stream (video) to a freshly formatted FAT file system. This allows cards that only buffer two "allocation units" [henceforth: AU] (which are typically much larger than "sectors" or "blocks" used by the file system) to run efficiently -- one AU holds the FAT bitmap, the other AU receives the video stream. When the stream AU is filled, the card physically writes it flash memory, then allocates a free AU and erases it (flash memory "writes" can only convert "1" bits in the AU into "0" bits, the AU has to be erased to convert back to all "1"), and continues recording the stream.

When such a (2 AU) card is used with a journalling file system, the OS writes the new data to some location (requires an AU erase/rewrite), writes the journal information (a log of where the new data was written -- the original directory scheme still points to the old data location; this is another AU erase/rewrite), and some time later the OS updates the main directory information using the journal (marking the original data locations free, and marks the journal free). If writes are modifying just a small file system sector/block, they still trigger a full AU erase, with the contents of the original AU copied (first to the buffer, where the new modified blocks are then written), before being committed to the flash memory.

Class 2/4/6 cards, OTOH, were rated based upon writing small files to fragmented file systems (still based on FAT but...) These cards often buffer 4 to 6 AUs at one time. As long as all file system updates occur within buffered AUs, one avoids excess erase cycles (one gets an erase cycle when the AU is first loaded for use, but with four AUs buffered, that could mean directory information, journal data, and actual data blocks are all being buffered, rather than swapping AU between data and journal, with each swap an new erase cycle). Much less wear on the flash memory, and possibly faster performance as one isn't slowed down by as many erase cycles.

From a test I'd done a while back:

Code: Select all

-=-=-=-	16 GB Kingston Class 10 in an R-Pi 3B+ (1.2GHz)
[email protected]:~/benchmark$ sudo ./benchmark.sh

Raspberry Pi Dramble microSD benchmarks
microSD clock: 50.000 MHz

Running hdparm test...

/dev/mmcblk0:
 HDIO_DRIVE_CMD(identify) failed: Invalid argument
 Timing buffered disk reads:  66 MB in  3.02 seconds =  21.85 MB/sec

Running dd test...

51200+0 records in
51200+0 records out
419430400 bytes (419 MB, 400 MiB) copied, 54.3339 s, 7.7 MB/s

Running iozone test...
        Iozone: Performance Test of File I/O
                Version $Revision: 3.434 $
                Compiled for 32 bit mode.
                Build: linux-arm

        Contributors:William Norcott, Don Capps, Isom Crawford, Kirby
Collins
                     Al Slater, Scott Rhine, Mike Wisner, Ken Goss
                     Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
                     Randy Dunlap, Mark Montague, Dan Million, Gavin
Brebner,
                     Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave
Boone,
                     Erik Habbinga, Kris Strecker, Walter Wong, Joshua
Root,
                     Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren
Sawyer,
                     Vangel Bojaxhi, Ben England, Vikentsi Lapa,
                     Alexey Skidanov.

        Run began: Tue May 19 13:38:19 2020

        Include fsync in write timing
        O_DIRECT feature enabled
        Auto Mode
        File size set to 102400 kB
        Record Size 4 kB
        Command line used: ./iozone -e -I -a -s 100M -r 4k -i 0 -i 1 -i 2
        Output is in kBytes/sec
        Time Resolution = 0.000001 seconds.
        Processor cache size set to 1024 kBytes.
        Processor cache line size set to 32 bytes.
        File stride size set to 17 * record size.
                                                              random random
bkwd    record    stride
              kB  reclen    write  rewrite    read    reread    read write
read   rewrite      read   fwrite frewrite    fread  freread
          102400       4      264      242     5349     5803     5136 239

iozone test complete.

microSD card benchmark complete!




-=-=-=-	8 GB SanDisk Class 4 in a BeagleBone Black (1GHz)
[email protected]:~/benchmark$ sudo ./benchmark.sh
[sudo] password for debian:

Raspberry Pi Dramble microSD benchmarks

Running hdparm test...

/dev/mmcblk0:
 HDIO_DRIVE_CMD(identify) failed: Invalid argument
 Timing buffered disk reads:  66 MB in  3.01 seconds =  21.89 MB/sec

Running dd test...

51200+0 records in
51200+0 records out
419430400 bytes (419 MB, 400 MiB) copied, 70.7736 s, 5.9 MB/s

Running iozone test...
        Iozone: Performance Test of File I/O
                Version $Revision: 3.434 $
                Compiled for 32 bit mode.
                Build: linux-arm

        Contributors:William Norcott, Don Capps, Isom Crawford, Kirby
Collins
                     Al Slater, Scott Rhine, Mike Wisner, Ken Goss
                     Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
                     Randy Dunlap, Mark Montague, Dan Million, Gavin
Brebner,
                     Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave
Boone,
                     Erik Habbinga, Kris Strecker, Walter Wong, Joshua
Root,
                     Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren
Sawyer,
                     Vangel Bojaxhi, Ben England, Vikentsi Lapa,
                     Alexey Skidanov.

        Run began: Tue May 19 13:26:14 2020

        Include fsync in write timing
        O_DIRECT feature enabled
        Auto Mode
        File size set to 102400 kB
        Record Size 4 kB
        Command line used: ./iozone -e -I -a -s 100M -r 4k -i 0 -i 1 -i 2
        Output is in kBytes/sec
        Time Resolution = 0.000001 seconds.
        Processor cache size set to 1024 kBytes.
        Processor cache line size set to 32 bytes.
        File stride size set to 17 * record size.
                                                              random random
bkwd    record    stride
              kB  reclen    write  rewrite    read    reread    read write
read   rewrite      read   fwrite frewrite    fread  freread
          102400       4     1192     1249     6587     6597     6541 635

iozone test complete.

microSD card benchmark complete!

[email protected]:~/benchmark$


	Things to note:

*	HDPARM speeds are very close, the R-Pi at 21.85 MB/s, the "slower" BBB
at 21.89 MB/s

*	DD test, R-Pi at 7.7 MB/s, BBB at 5.9 MB/s

*	But iozone shows extreme differences!
													Random	 Random
					Write	Rewrite	Read	Reread	Read	 Write
R-Pi: 102400       4      264      242     5349     5803     5136      239 
BBB: 102400       4     1192     1249    6587     6597     6541      635  
   
	Speed multiple	4.5X	5.2X	1.2X	1.1X	1.3X	2.7X
The "slow" Class 4 card, in a slower processor (single core BBB vs multicore R-Pi 3B) outperformed the "fast" Class 10 card on write/rewrite/random-write, and even beat it on simple (no erase cycle) read/reread/random-read timings.

--
AF6VN
Dennis L Bieber

G4TVP
Posts: 26
Joined: Mon Feb 03, 2020 11:30 pm

Re: Cannot connect to Brandmeister network

Post by G4TVP » Sun Jul 26, 2020 5:47 pm

I've also tried a SanDisk 32gb and that also gives the same errors, but don't have any others to try. As I said, it has been working fine with Dstar for 6mths+.

There isn't much too it surely, change the setting and click "Apply Changes"?

This is a cheapie Chinese MMDVM purchased from a radio rally in the UK. I have set it to "MMDVM_HS_HAT (DB9MAT & DF2ET) with Pi GPIO".

What does the error "Unable to read the firmware version after six attempts" mean, a hardware fault with the chip or software configuration issues?

G8SEZ
Posts: 216
Joined: Fri Apr 13, 2018 8:26 pm

Re: Cannot connect to Brandmeister network

Post by G8SEZ » Sun Jul 26, 2020 6:39 pm

One suggestion, try reflashing the modem firmware, it might help.
--

Brian G8SEZ

G4TVP
Posts: 26
Joined: Mon Feb 03, 2020 11:30 pm

Re: Cannot connect to Brandmeister network

Post by G4TVP » Sun Jul 26, 2020 7:09 pm

Was that "sudo pistar-mmdvmhshatflash hs_hat". If so, I believe we tried that on Tuesday?

There is another cheapie MMDVM board coming from Ebay as per your suggestion yesterday, on the basis they are as cheap as chips, so why not. I've also asked Flo (DF2ET) if I can purchase a pucka MMDVM board. My gut feeling is that this is a hardware issue, as I tried your config yesterday afternoon, to no avail (was getting a constant carrier).

Would be interested to know where this error message (Unable to read the firmware version after six attempts & the RX overflow) originates and is the source code available ?

KE7FNS
Posts: 943
Joined: Wed Apr 17, 2019 11:11 pm

Re: Cannot connect to Brandmeister network

Post by KE7FNS » Sun Jul 26, 2020 7:54 pm

G4TVP wrote:
Sun Jul 26, 2020 5:47 pm
I've also tried a SanDisk 32gb and that also gives the same errors, but don't have any others to try. As I said, it has been working fine with Dstar for 6mths+.

There isn't much too it surely, change the setting and click "Apply Changes"?
Are you clicking apply changes in each section when you make a change in that section or are you just clicking apply changes once after you have made changes over all the sections? Are you patiently waiting for the page to refresh by itself or are you manually refreshing it? Does it show your updated changes such as your DMR ID in the textboxes when the new page refreshes?? What happens after you reboot your hotspot, does it keep any of your changes????

Since you have reported that changes are not being stored correctly, that indicates to me that there is an issue writing to the SD card, which is a completely separate issue from a modem communication issue. Its also possible that it is an issue caused by the user not using the configuration pages properly. When troubleshooting you have to account for all the possible issues, so don't be offended, it isn't anything personal.

The communication failure might be related because the serial port settings are contained in the same configuration file and if the settings are not being written correctly that might be the underlying cause.
G4TVP wrote:
Sun Jul 26, 2020 5:47 pm
This is a cheapie Chinese MMDVM purchased from a radio rally in the UK.
That doesn't tell anyone enough info to determine which hat you have. What does it say on the PCB silkscreen or post a photo, normally there is an identifier like MMDVM_HS etc etc.
G4TVP wrote:
Sun Jul 26, 2020 5:47 pm
What does the error "Unable to read the firmware version after six attempts" mean, a hardware fault with the chip or software configuration issues?
Again, I am just repeating myself and you are not listening, you cannot determine if the problem is software or hardware from that error message. All that specific message tells you is something went wrong at some point communicating with the modem. You need to provide more detailed information like did it boot and work correctly for X amount of minutes, or did it boot and fail instantly on the first attempted communication. One of those would be indicative of a software configuration problem, and the other a hardware problem.

You've posted that you flashed the firmware, and I asked you what the modem LED's do on powerup. You never bothered to answer that question and it is fairly important in this situation. It could be something as simple as you flashing the wrong firmware for that specific hat and that is why the modem now fails to communicate.
If someones previous actions are any indication of their future actions, then I predict the deletion and removal of access will happen at any moment. 7-11-2020.

"07/13/20 This Website Has Been Taken Down" ... again :lol:

G4TVP
Posts: 26
Joined: Mon Feb 03, 2020 11:30 pm

Re: Cannot connect to Brandmeister network

Post by G4TVP » Sun Jul 26, 2020 8:53 pm

1/. I am click "applying changes" after making changes into each section and waiting for the page to refresh. The changes I've made (such as DMR id) are been reflected on screen. Post reboot, all changes are present and correct.
2/. With this SD card, changes did get reflected in the full-edit DMR gateway section, although I can't recall doing anything different on this occasion.
3/. I can't see any "words" on the MMDVM silk screen so have posted pictures of both sides.
4/. I have gone back to trying Dstar with this board and that works flawlessly.
5/. Disabling Dstar for the moment, and going back to DMR (by changing the MMDVMHost configuration), on the dashboard, both DMR in "modes enabled" and "network status" show up in RED, immediately. I have a GREED pwr led and a solid RED svc led. In the MMDVM log, in /var/log/pi-star, the last entries are as follows:-
E: 2020-07-26 20:35:52.074 No reply from the modem for some time, resetting it
M: 2020-07-26 20:35:52.074 Closing the MMDVM
M: 2020-07-26 20:35:54.075 Opening the MMDVM
E: 2020-07-26 20:36:06.902 Unable to read the firmware version after six attempts
M: 2020-07-26 20:36:11.903 Opening the MMDVM
6/. Just to re-iterate, on power-up, DMR has in the past worked for <5secs and then hung and presently, I get nothing. I will admit, this could be due to a lack of knowledge on how to configure it, which is why I tried with Brian's configuration yesterday.
7/. Flashing was done earlier in the week using this command "sudo pistar-mmdvmhshatflash hs_hat". Please let me know if that is not correct?
8/. Also included is a screenshot of the main configuration, just in case there is something wrong in that section.

Hope that helps and if there is any more info you require, please let me know.
Attachments
Screenshot 2020-07-26 21.47.26.png
Screenshot 2020-07-26 21.47.26.png (125.06 KiB) Viewed 353 times
bottomside_mmdvm.jpg
bottomside_mmdvm.jpg (140.71 KiB) Viewed 353 times
topside_mmdvm.jpg
topside_mmdvm.jpg (224.75 KiB) Viewed 353 times

KE7FNS
Posts: 943
Joined: Wed Apr 17, 2019 11:11 pm

Re: Cannot connect to Brandmeister network

Post by KE7FNS » Sun Jul 26, 2020 10:33 pm

G4TVP wrote:
Sun Jul 26, 2020 8:53 pm
1/. I am click "applying changes" after making changes into each section and waiting for the page to refresh. The changes I've made (such as DMR id) are been reflected on screen. Post reboot, all changes are present and correct.
Ok, well if the changes are being displayed correctly especially after a reboot, then that eliminates any question about it not saving them correctly.
G4TVP wrote:
Sun Jul 26, 2020 8:53 pm
2/. With this SD card, changes did get reflected in the full-edit DMR gateway section, although I can't recall doing anything different on this occasion.
Same answer as last response.
G4TVP wrote:
Sun Jul 26, 2020 8:53 pm
3/. I can't see any "words" on the MMDVM silk screen so have posted pictures of both sides.
Under the OLED is where the identification is normally at on that board style (at least on the original non cloned versions). It is slightly above the antenna connector and a bit to the right under the left side of the OLED board. You might be able to see it if if you shine a light and look at it from a sharp angle, but that isn't really necessary. The board is a Jumbospot or a clone of one. A clone may or may not contain an identifier sometimes the silkscreen layout is edited on purpose when the files are sent to the PCB printing factory.

The modem selection setting for a Jumbospot board is:
STM32-DVM / MMDVM_HS - Raspberry Pi Hat (GPIO)
G4TVP wrote:
Sun Jul 26, 2020 8:53 pm
4/. I have gone back to trying Dstar with this board and that works flawlessly.
That is really odd, it doesn't make any sense that DMR would fail, and DStar would function correctly. That sort of changes things greatly and moves my suspicion to a software bug in the DMR code in MMDVMHost or in the MMDVM_HS firmware neither of which are easy to pinpoint or solve especially when you seem to be the only person reporting the issue.
G4TVP wrote:
Sun Jul 26, 2020 8:53 pm
5/. Disabling Dstar for the moment, and going back to DMR (by changing the MMDVMHost configuration), on the dashboard, both DMR in "modes enabled" and "network status" show up in RED, immediately. I have a GREED pwr led and a solid RED svc led. In the MMDVM log, in /var/log/pi-star, the last entries are as follows:-
It is normal for the mode indicators on the dashboard to go red when applying changes, as it has to restart the services. It takes a bit for them to come back online.
G4TVP wrote:
Sun Jul 26, 2020 8:53 pm
6/. Just to re-iterate, on power-up, DMR has in the past worked for <5secs and then hung and presently, I get nothing. I will admit, this could be due to a lack of knowledge on how to configure it, which is why I tried with Brian's configuration yesterday.
What do the LED's on the modem hat do on a powerup from off? They should all flash, and blink etc.
G4TVP wrote:
Sun Jul 26, 2020 8:53 pm
7/. Flashing was done earlier in the week using this command "sudo pistar-mmdvmhshatflash hs_hat". Please let me know if that is not correct?
That appears to be the correct command, but I'd like to know what version it reports. Should be near the start of the MMDVMhost log. 1.4.17 is the latest stable version with 1.5.1 being a beta.
G4TVP wrote:
Sun Jul 26, 2020 8:53 pm
8/. Also included is a screenshot of the main configuration, just in case there is something wrong in that section.

Hope that helps and if there is any more info you require, please let me know.
I don't see anything out of place except the modem selection and that isn't all that critical. There are a few hats that can function correctly using different selections. So I don't think that is going to have any major effect on the problem you have encountered.

Is this a RPi 1 or 2?
If someones previous actions are any indication of their future actions, then I predict the deletion and removal of access will happen at any moment. 7-11-2020.

"07/13/20 This Website Has Been Taken Down" ... again :lol:

Post Reply