MMDVM_HS hat does not receive from Yaesu FT1D

[Twilight-Logic]

I have an issue with an MMDVM_HS hat on my Pi in that it will not receive from a Yaesu FT1D. The pi-star configuration previously worked with the FT70D.

The following findings are evident:

• all devices are set for 438.8MHz as per Hotspot default
• the Hotspot transmits and the FT1D decodes into audio nice and clear
• the FT1D can be heard transmitting data hash on another radio and is on frequency
• the Hotspot shows no activity on receive at all - nothing on the dashboard, no LEDs light up on the board, nothing in log

The FT1D has been tested in both WV and DN modes as well as with Half_deviation turned ON and OFF with matching setting on the hotspot. Examining the waterfall on an SDR shows both Hotspot and FT1D pretty much spot on 438.8. There is a deviation of about 250hz and the offset on the Hotspot has been adjusted to compensate for this but it makes not difference. Incremental offsets of 100hz between -2000 and to +2000 have been tested without any result.

From discussions with others I have confirmed that the MMDVM_HS Hotspot 1.4.17 firmware works with the FT2D, FT3D and FT70D but I can't get it to work with the FT1D.

Is the ADF7021 chip somehow incompatible with the FT1D, or is the firmware missing something? Any help with diagnostics will be greatly appreciated and I am willing to feed back any helpful information if it will benefit others in the same predicament.

[rogerclarkmelbourne]

Many radios have compatibility problems with the ADF7021 based hotspots, but its interesting to see its not just the cheap Chinese radios which have this problem

When TYT initially released the GD-73 (This is the Radioddity model number, I can't remember the TYT internal model number for this radio), it would not work with hotspots as the BER was very high, and no adjustments to the hotspot seemed to be able to fix this.

TYT had to make some modifications to their firmware to resolve the problem, and now AFIK the GD-77 works fine with hotspots

So, even though this is a Yaesu radio, its probably incumbent on Yaesu to investigate and fix this problem, because no matter where the fault lies, most other radios do work with the ADF7021 based hotspots, so Yaesu must be doing something non-standard.

BTW. The GDF-73 is a DMR radio, but I think the same applies in terms of modulation, because C4FM also uses 4FSK like DMR.

[Twilight-Logic]

So, even though this is a Yaesu radio, its probably incumbent on Yaesu to investigate and fix this problem, because no matter where the fault lies, most other radios do work with the ADF7021 based hotspots, so Yaesu must be doing something non-standard.

Yaesu will only say that they can guarantee their C4FM products are compatible with each other (which they are). Their protocol is proprietary and they can't vouch for 3rd party products that they didn't develop so in a sense that is fair.

Looking at the datasheet, the ADF7021 appears to be a NFM radio chip with an FSK demodulator for receive and modulator for transmit. Beyond that the data received is handled by the firmware which interprets it and does something with it. It is possible, I guess, that the C4FM implementation on the older FT1D is subtly different somehow from the implementation on the FT70D, FT2D and FT3D and the firmware is simply not programmed to identify the difference and just ignores it. So the question from my perspective is, how to determine whether that is the case and if so, whether the firmware can be adjusted to identify C4FM generated by the FT1D? While I have it, my FT1D is available for testing and I am happy to carry out any tests such as the devs may require to resolve the problem.

Other than that I guess the alternative it to buy a hotspot that does not rely on the MMDVM_HS firmware, or buy another radio.

[rogerclarkmelbourne]

Their protocol is proprietary, but the modulation mode isn't

AFIK, The MMDVM based hotspots don't do any processing of the 4FSK bitstream, its just passed as raw data to MMVDMHost, which does all the magic.

I doubt MMDVMHost does much processing because like you say, its a proprietary protocol.

I know on DMR MMDHMHost doesn't process the 4FSK bitstream, it just parses it to get the source and destination ID's and and does error correction on the data before sending the raw bitstream in a wrapper to the server.

I'm not a developer on this project, but since development is non-commercial, I think its unlikely that anyone is going to buy a FT1D just to get it working with this hardware.

Also, I suspect most other hotspots also use the ADF7021.

[N4IRS]

I can't speak to the current firmware, I have not done a update (to either device) in a while, but I can tell you the FT1D has worked in the past with MMDVM_HS

[rogerclarkmelbourne]

@N4IRS

In that case @Twilight-Logic could try installing an older version of the firmware onto the hotspot.

Or possibly Yaesu changed something in their hardware or firmware.

[N4IRS]

I would suggest backing off to a older version of the MMDVM_HS firmware. I don't remember seeing any traffic about the FT1D on the OpenDV list. I'm sure there are quite a few FT1Ds out in the field.

[g4klx]

I am using my FT-1D (DSP version 4.15, firmware version 3.0.1) with hostspot FW 1.4.14 (20181209) and it works very well indeed. Indeed I am using that combination for the new System Fusion gateway development. Jonathan  G4KLX

On Wednesday, 28 October 2020, 23:38:19 GMT, Steve Zingman <notifications@github.com> wrote:  

I would suggest backing off to a older version of the MMDVM_HS firmware. I don't remember seeing any traffic about the FT1D on the OpenDV list. I'm sure there are quite a few FT1Ds out in the field.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[Twilight-Logic]

I am using my FT-1D (DSP version 4.15, firmware version 3.0.1) with hostspot FW 1.4.14 (20181209) and it works very well indeed. Indeed I am using that combination for the new System Fusion gateway development. Jonathan G4KLX

Jonathan, thank you for this mention further to the discussion on the OARC discord the other night. provides some hope since you appear to be using exactly the same hardware as I am and with the same versions of the radio firmware. Can I ask which modem option you are using?

I have tried both of these options which seemed the most appropriate:

STM32-DVM / MMDVM_HS - Rapberry Pi Hat (GPIO) MMDVM_HS_Hat (DB9MAT & DF2ET) for Pi (GPIO)

Indeed I have been advised that the first one is the one to use. I have had the same issue with both. My modem hardware version is reported as follows using pistar-findmodem:

pi-star@pi-star(ro):~$ pistar-findmodem Detected MMDVM_HS (GPIO): /dev/ttyAMA0 (MMDVM_HS_Hat-v1.4.17 20190529 14.7456MHz ADF7021 FW by CA6JAU GitID #cc451c4)

There isn't an option on the list for a "CA6JAU" version, but your firmware version 1.4.14 is slightly earlier and it sounds like it might be worth giving a try. I downgraded the modem firmware using pistar-mmdvmhshatdowngrade to 1.4.14, but this has not yet solved the problem.

pi-star@pi-star(ro):~$ pistar-findmodem Detected MMDVM_HS (GPIO): /dev/ttyAMA0 (MMDVM_HS_Hat-v1.4.14 20181209 14.7456MHz ADF7021 FW by CA6JAU GitID #8d77ff3)

[juribeparada]

I have done all MMDVM_HS firmware development and testing with a FT1XD (firmware ver. 13.0.1, dsp ver. 4.15), and using latest fw 1.4.17 on an original HS Hat all work fine (normal or half deviation, VW or DN, etc). It is not possible that ADF7021 could be incompatible with the FT1D (it is just 4FSK), and I don't believe a firmware problem for now. It has to be another issue, not sure at the moment. Are you using 50 % deviation settings in Pi-Star configuration, for example?. And just in case, have you tested another frequency?

[Twilight-Logic]

That's interesting. I have re-instated 1.4.17 on my board. I didn't think it could be the ADF7012 chip either. AFAIK I am not using 50% deviation settings in the pi-star configuration. Under System Fusion in Expert settings, LowDeviation is set to 0. On the radio HALF DEVIATION is set to OFF. In answer to your ither question, yes, I have tested at least a couple more frequencies in th 70cm band.

I have to add a note here that I have discovered from my discussion with G4KLX that the MMDVM board I am using is an "illegal copy" and not officially supported. I was previously unaware of that fact and based on information from various sources including videos and reviews was under the impression (as are other people it seems) that all those MMDVM boards available for sale on eBay are open source, and legit to purchase. A number of people I have discussed this problem of using it with the FT1D with said they use such boards with success. I used mine with success when I had the FT70D so in principle it has to be said that the board hardware works.

Now that I know, I have decided to purchase an officially supported MMDVM hat although I don't beleive that is necessarily the answer. You refer to an "original HS Hat". Are we talking about Zumspot, BI7JTA or something else?

[juribeparada]

OK, just In case, all deviation settings should be 50 % in order to use standards deviations for each DV mode, and then a proper working of the board (see the README of this repository). I am using MMDVM_HS_Hat from DB9MAT & DF2ET, but I have also a ZumSpot and BI7JTA boards. The main problem with the board copies is they generally use a low quality TCXO, which produces large frequency offset errors...and also clock recovery errors (these can't be fixed). The clock recovery system of the ADF7021 is very limited, then a very good TCXO is desired for low BER. I wonder if you have tried any other DV mode, like DMR for example?

[Twilight-Logic]

No, sorry, I do not have a DMR radio so would need to purchase one such as maybe the Baofeng DM-5R. However, the cost is about the same as a duplex BI7JTA hat so its a case of deciding which on to spend the money on!

Thank you for your detailed response which is much appreciated. I had a another look at the readme as suggested and this is the modem section on my pi-star:

[Modem] Port=/dev/ttyAMA0 TXInvert=1 RXInvert=0 PTTInvert=0 TXDelay=100 RXOffset=0 TXOffset=0 DMRDelay=0 RXLevel=50 TXLevel=50 RXDCOffset=0 TXDCOffset=0 RFLevel=100 CWIdTXLevel=50 D-StarTXLevel=50 DMRTXLevel=50 YSFTXLevel=50 P25TXLevel=50 NXDNTXLevel=50 POCSAGTXLevel=50 RSSIMappingFile=/usr/local/etc/RSSI.dat Trace=0 Debug=0

So it seems settings are at 50% for YSF and TXLevel as described. I have approached DF2ET for an original board as discussed on his site. I am also considering purchase of either the DB9MAT & DF2ET and the BI7JTA hat.

[Twilight-Logic]

Just been watching your video here:

https://www.youtube.com/watch?v=CuSfqcgB-UU

Sorry, I don't understand the Spanish, but I see you are using your FT1XD!. On the Mac I see you are SSH'd in to the pistar. How do you bring up that log on the command line? Is this the same as the "Live Log"? I would prefer to see that on the command line myself is possible.

[juribeparada]

Just to have a detailed log, you need to increase the log level in the [Log] section first: FileLevel=1

It could be useful to activate the debug of the modem in the [Modem] section (only recommended for your problem now): Debug=1

(the configuration file is in /etc/mmdvmhost)

Then, you can see the modem log: tail -f /var/log/pi-star/MMDVM-2020-XX-XX.log

(a log file is created each day)

[Twilight-Logic]

Thank you. I didn't realize one could use the tail command like that.

Unfortunately, even with debug on, I get absolutely nothing when I key the PTT.

[juribeparada]

Well, in that case, it is really not decoding even the YSF sync signature. I can only think in the following reasons: 1) Bad deviation (which is not the case) 2) Very big frequency offset (it could be since the board is a copy) 3) Strong RF interference (it seems not the case, but I heard people experience with bad AC adaptors for example) 4) Radio not sending the expected YSF sync bit sequence (very strange...) 5) Board malfunction (also strange if you tested with other YSF radio...)

[Twilight-Logic]

Thank you. I need to think this through.

Since there is nothing in the log, if I probe the data wires between the ADF7021 and STM32F103, I should be able to see data being passed on receive to the STM32F103 right?

Seems that 1 is ruled out and probably no. 5, however, I didn't test this specific board with the FT70, but my previous one which is identical and was working last time it was used. Could both boards have the same weird fault? Regarding 2, I tried offsets between -10,000 and +10,000 in steps of 1000 but still getting nothing. I will try smaller steps when I have more time. There is some EMF noise from the PC but since the FT70D did not have a problem, there is no reason for the FT1D to have one. I did also try another PSU with no result. No. 4 would be rather strange since it works with YSF repeaters but it would require some way of analysing the signal.

Thank you for the summary.

UPDATE: I probed the SREAD and SDATA pins on the ADF7021 and I see a signal to SREAD from the STM32 when I turn the transmiter on and off. I can also see a signal from SDATA to the STM32 when I key the radio so it seems that the ADF7021 is receiving something from the radio. Whether that signal is correct unfortunately I have no way of knowing.

[Twilight-Logic]

I have ordered a simplex hat from BI7JTA. It will take a few days to arrive here. I will update when it arrives and I have had the opportunity to test it.

[Twilight-Logic]

I received the new BI7JTA board today but am getting the same problem! Behaviour is exactly the same as with the clone.

Board details: Detected MMDVM_HS (GPIO): /dev/ttyAMA0 (MMDVM_HS_Hat-v1.5.1b 20191201 14.7456MHz ADF7021 FW by CA6JAU GitID #146e6fbFF3906753648363051131516)

[juribeparada]

Well, really not sure what can be the problem, I am still using my FT1D without any issue. Just try different frequency offsets and be sure you are using latest Yaesu fw. Have you tried a factory reset of the radio (just in case)?

[Twilight-Logic]

I was a bit reluctant to reset it again, but I have just done as you recommended, both reset and playing with offsets, but it hasn't helped. Still getting absolutely nothing in the log or audio. Its clearly not detecting the YSF the radio is sending.

I now have an Icom radio here as well. Once I get the needed power supply (hopefully tomorrow) then I will then test D-Star as well.

In the meantime, I downloaded and compiled gr-ysf in the hope that I can determine exactly what FT1D sending:

https://github.com/HB9UF/gr-ysf

It is an experimental program and I have yet to figure out how to hook it up to the rtlsdr but if I can, then hopefully it might yield some useful YSF data to have a look at.

UPDATE: Got gr-ysf set up and running with the RTLSDR, but although I am seeing and have centered the signal in the bandscope, I am not getting any data output which is very much like with pi-star. Unfortunately still no helpful data at this point.

[Twilight-Logic]

My investigations with gr-ysf (with gnuradio-companion) determined that RAW data is being received from gr-osmocom, but cannot be decoded by the YSF deframer. In DSDplus decoding was rather poor with quite a few CRC errors being reported on frames. The conclusion seems to be that the frames are garbled somehow and therefore being ignored by the decoder. It is odd though that the radio works with a YSF repeater, but not with other software such as SDR radios and pistar. It looks like I will be returning the radio.

[juribeparada]

Well, that is really strange, but good to see that you discovered some possible causes of the problem. Anyway, have you had the chance to test with D-Star or DMR?

[Twilight-Logic]

Yes, I have tried it with D-Star. I did have some difficulty but was able to successfully perform an Echo test and get a playback of my call from the pistar. This at least proves that comms between the radio and MMDVM hat ar fine. I was able to connect with and listen to a couple of D-Star repeaters (REF001, DS477) and had a short QSO. Pistar showed my callsign and Tx status as well as incoming callsigns on the dashboard. It took quite a while for anyone to respond to my calls, but eventually someone did. Apparently during the QSO audio from my end cut out abruptly although and although I could still hear my contact, I could not re-establish communication. Not sure why that happened but it may have been a D-Star or pistar issue rather than the MMDVM hat hardware. Subsequent Echo tests worked perfectly fine but I never got any further contacts that day.

Still, this is different to YSF where the neither the MMDVM nor pistar showed any indication that YSF was being received and no echo test was possible.

[cwawak]

I'm seeing exactly this on a 7250, with my FT3D and FTM-300 working fine. https://github.com/juribeparada/MMDVM_HS/issues/143

[cwawak]

After adjusting RXOffset, I seem to be getting adequate performance with all my system fusion radios now.

[Twilight-Logic]

It has been a few months but I just wanted to update the topic one final time. I never did resolve the problem with the original FT1D despite countless hours of tweaking and experimenting. Eventually, I ended up selling it and buying another used one to replace it. This replacement FT1D worked just fine, so evidently the problem, which persisted despite firmware updates, was somehow related to the YSF transmission on the original radio which was received fine by local YSF repeaters but for some reason not with the Pistar.