Cannot connect to Brandmeister network

Help with DMR issues
AF6VN
Posts: 821
Joined: Fri Jul 20, 2018 1:15 am

Re: Cannot connect to Brandmeister network

Post by AF6VN »

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)
pi@rpi3bplus-1:~/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)
debian@beaglebone:~/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!

debian@beaglebone:~/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 »

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?
User avatar
G8SEZ
Posts: 555
Joined: Fri Apr 13, 2018 8:26 pm

Re: Cannot connect to Brandmeister network

Post by G8SEZ »

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 »

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 ?
G4TVP
Posts: 26
Joined: Mon Feb 03, 2020 11:30 pm

Re: Cannot connect to Brandmeister network

Post by G4TVP »

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 (124.61 KiB) Viewed 3180 times
bottomside_mmdvm.jpg
bottomside_mmdvm.jpg (140.27 KiB) Viewed 3180 times
topside_mmdvm.jpg
topside_mmdvm.jpg (224.02 KiB) Viewed 3180 times
M1DNS
Pi-Star Team
Posts: 1394
Joined: Thu Apr 05, 2018 5:30 am

Re: Cannot connect to Brandmeister network

Post by M1DNS »

Remember each network will have its own login criteria which needs to match. I saw a post recently on the BM telegram group where ID 1234567 has been blacklisted, it was seen to be being misused on several occasions. It was choosen as the default as it wouldnt usually be used as live ID but now it will be completly unusable on BM so it wont connect there But this same ID could possibly be accepted to work over a DSTAR or YSF network as each is different.

Sent from my SM-G935F using Tapatalk



Andrew M1DNS.
Pi-star Admin Team.
User avatar
G8SEZ
Posts: 555
Joined: Fri Apr 13, 2018 8:26 pm

Re: Cannot connect to Brandmeister network

Post by G8SEZ »

KE7FNS wrote: Sun Jul 26, 2020 10:33 pm
The modem selection setting for a Jumbospot board is:
STM32-DVM / MMDVM_HS - Raspberry Pi Hat (GPIO)
I found with my very first Jumbospot board 2 or 3 years ago that this modem selection didn't work, and I had the same symptoms with the "couldn't read firmware version after 6 attempts" error.

I ended up using the MMDVM_HS_HAT (DB9MAT & DF2ET) for Pi (GPIO) selection, but there were also numerous firmware updates (I think I started with version 1.3.5). There is some confusion over the HS_HAT boards, because the early "genuine" ones with hardware versions less than 1.3 were a bit different. Later Jumbospots were built to v1.6 standard which has been a lot more stable, I hacked in some of the changes to my boards, one in particular was the filtering on the 3.3v rail, the later dual HAT board uses a regulator taken from the +5v rail as this ensures a more stable voltage and it isn't affected by the changing 3.3v load on the RPi itself.

I now have a Dual_HS_HAT board and it is a lot more forgiving even though it takes up over twice the area of the Pi Zero sized HATs.
--

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

Re: Cannot connect to Brandmeister network

Post by G4TVP »

1/. I've prized the OLED up as far as I dare and can't see any identification marked around the antenna/OLED area, sorry!
2/. I have changed the modem selection to "STM32-DVM / MMDVM_HS - Raspberry Pi Hat (GPIO)", but no difference.
3/. All leds (except power) blink 3 times on startup. The SVC goes off and on a few times. It it helps, I maybe could record a video of startup and post that somewhere for you to look?
4/. Couldn't see any sign of the version in the logfile, but the Dashboard reports "HS_Hat:v1.4.17"
5/. This is a Pi zero 1.1. I did also try the HAT on my other Pi-zero to be sure, which also says "Pi Zero W v1.1" on the silkscreen. Is that what you mean't?

Hopefully by the end of this week, I will get another MMDVM board from Ebay.

Thank you for investing the time to try to get to the bottom of this issue. Hopefully I have answered all your questions.
AF6VN
Posts: 821
Joined: Fri Jul 20, 2018 1:15 am

Re: Cannot connect to Brandmeister network

Post by AF6VN »

M1DNS wrote: Mon Jul 27, 2020 10:23 am ID 1234567 has been blacklisted <SNIP> But this same ID could possibly be accepted to work over a DSTAR
To my knowledge, D-STAR doesn't use DMR-style ID numbers; as an amateur-only protocol, it was designed from the start to use actual call-signs. In the business world, DMR IDs are similar to private LAN IP addresses -- they get issued by the company providing radio service (end users don't get to configure the radios, the provider -- who likely also operates/installs a repeater, defines talk groups for the client, who also provides a list of users to programmed into the radios. NXDN is likely similar. I'm surprised if YSF doesn't use call signs directly.

--
AF6VN
Dennis L Bieber
User avatar
G8SEZ
Posts: 555
Joined: Fri Apr 13, 2018 8:26 pm

Re: Cannot connect to Brandmeister network

Post by G8SEZ »

AF6VN wrote: Mon Jul 27, 2020 3:54 pm
M1DNS wrote: Mon Jul 27, 2020 10:23 am ID 1234567 has been blacklisted <SNIP> But this same ID could possibly be accepted to work over a DSTAR
To my knowledge, D-STAR doesn't use DMR-style ID numbers; as an amateur-only protocol, it was designed from the start to use actual call-signs. In the business world, DMR IDs are similar to private LAN IP addresses -- they get issued by the company providing radio service (end users don't get to configure the radios, the provider -- who likely also operates/installs a repeater, defines talk groups for the client, who also provides a list of users to programmed into the radios. NXDN is likely similar. I'm surprised if YSF doesn't use call signs directly.
YSF does use callsigns but it also has the concept of a radio ID which is supposed to be unique to each radio Yaesu produces. It's a 5 digit alphanumeric.

As ever radio amateurs modify things for their own convenience and some manufacturers provide more facilities than their commercial users demand because they know that amateurs buy them.

I am frankly amazed that all the modes and networks hang together as well as they do.
--

Brian G8SEZ
Post Reply