Pi-Star hotspot does not receive from FT1D

[G8SEZ]

The reason that some people don't like the Chinese clones is because they were sold with the intent of making a profit, apparently.

Actually since the original boards were more expensive when bought in Europe I doubt it's true but then people are free to believe what they like and buy what they want.

The only issue you might see with the clones is that they don't have the correct component values, although this is hard to prove, and they might have cheaper TCXOs which are off frequency and have a poorer temperature coefficient. I changed mine for known good ones.

[M7YTH]

I have been made aware of the TXCO issue and been advised that the clones substitute cheaper components although I wasn't aware that they might not have correct component values. Nevertheless the board uses the same antenna for Rx and Tx and it seems to me that if signal gets out it should also get in. I know signal gets in because it worked with the FT70D. Whether genuine or original, both use the same chips, i.e. ADF7012 and STM32F103. That the implementation on the clone boards is likely to be cheaper and therefore have inferior performance I guess is to be expected, hence the offset values to compensate. AFAIKT, transmit from the hat is about -250Hz off what the SDR is telling me, so I should be able to compensate with a +250 offset. That does get the Tx signal about spot on.

I can understand developers being angry about the market being flooded with clones. Its also difficult for buyers to figure out which ones are clones and which ones are now. The 10x price differential (Zumspot) is not exactly helpful either. Something similar happened with Salaeae. Now have all those LA clones.

Still, downgrading the firware to v1.4.14 to match the version G4KLX was using successfully did not solve the problem so it doesn't look like its the firmware.

[M7YTH]

Some hams would rather buy cheaper equipment and buy more equipment with the same amount of money.

Not all of us can afford to pay 1000s for the latest kit. I don't have a HF rig or decent antenna yet, but when I do get around to it , its likely to be an older 1990s rig that I can afford.

BTW, which board do you have? Take a photo of it and post it, I'd like to see. I might be able to dig up the design documents and with a little magnification you should be able to compare components and layouts.

I have attached pic below. I apologies for the small size, but I had to shrink it that far before the forum would allow me to attach it. The wires are the 1602 I2C display connection. The display is 5V so I am using a level shifter to convert the I2C data logic level between 3V3 and 5V hence both the 3V3 and 5V connections. The display will run off 3V3 with some loss of brightness/contrast but is much clearer when running at 5V.

I am intending to purchase one of these which is "officially supported" but looks very similar indeed:

https://www.bi7jta.org/cart/index.php?r ... duct_id=69

or the duplex variant:

https://www.bi7jta.org/cart/index.php?r ... duct_id=50

Not sure yet whether to go for the simplex or the duplex version? Is this just preference or is there an advantage in a home hotspot setting.

I have the Pi so I don't need a full PiZero setup, just the hat.

D2FET_eBay_hat_640.jpg (219.63 KiB) Viewed 2494 times

[G8SEZ]

I'm not a fan of the dumb design decision to put the OLED in the same area where the RPi's 40 pin GPIO connector is. That just seems like an accident waiting to happen.

It was done because it's the only way to get the 0.96" OLED to fit inside a Pi Zero sized case, but it certainly has the ability to screw things up if you're not careful. More to the point it means that any remedial work near the ADF7021 requires removing the OLED.

[M7YTH]

Thank you for the information.

I probed the SREAD and SDATA wires between the ADF7021 and STM32F103 while controling the board with MMDVMcal. I can see a signal on SREAD when I send the DMR test pattern for example when I turn on the transmitter. With the transmitter off, I can also see a signal on SDATA when I key the radio, so it would seem that something is coming through the ADF7021 and being passed to the STM32. Whether the output from the ADF7021 is correct for the STM32 to be able to decode I do not have the means to determine so have no way of knowing.

I did check for a clock signal on the TXCO and I measured it with the scope at somewhere around 14.70-14.90 but it was difficult to be precise. I didn't take note of whether the signal varied much so will take another look later and see whether I can hook up a frequency counter to give a more precise reading.

Would this board here be OK to buy?

https://www.bi7jta.org/cart/index.php?r ... duct_id=69

Or is this also the old design?

[G8SEZ]

It was done because it's the only way to get the 0.96" OLED to fit inside a Pi Zero sized case, but it certainly has the ability to screw things up if you're not careful.

I don't see it as the only way, they could of rotated the OLED 180 degrees and the pins would no longer be in any conflict with the GPIO. The orientation of the board/RPi combo is irrelevant, if the image on the OLED is upside down, you just rotate the entire case instead. Its even easier to deal with now that theres been configuration options to MMDVMHost to account for the OLED display rotation, so now you don't even have to rotate the case, you can leave it alone.

I think that they took the simplest route to something that works but requires care to ensure no shorts after assembly. It looks like we're stuck with it for the cheapest Pi Zero hotspots. Yes, the ability to invert the display is useful, but if the OLED were on the opposite edge then it would be the correct way up with the HS on its side with the power connection on top of the case.

I see that the original developers have created a v2.0 board, which they say works well, but I have not seen the layout nor whether it has improved display connectivity. No idea when it will be available, probably due to the current worldwide insanity over Covid19.

[G8SEZ]

Thank you for the information.

I probed the SREAD and SDATA wires between the ADF7021 and STM32F103 while controling the board with MMDVMcal. I can see a signal on SREAD when I send the DMR test pattern for example when I turn on the transmitter. With the transmitter off, I can also see a signal on SDATA when I key the radio, so it would seem that something is coming through the ADF7021 and being passed to the STM32. Whether the output from the ADF7021 is correct for the STM32 to be able to decode I do not have the means to determine so have no way of knowing.

I did check for a clock signal on the TXCO and I measured it with the scope at somewhere around 14.70-14.90 but it was difficult to be precise. I didn't take note of whether the signal varied much so will take another look later and see whether I can hook up a frequency counter to give a more precise reading.

Would this board here be OK to buy?

https://www.bi7jta.org/cart/index.php?r ... duct_id=69

Or is this also the old design?

It gets complicated. I would say that this is a Chinese modification of the v1.6 board from DB9MAT and DF2ET but with most of the GPIO pins removed and the OLED 4 pin connector on the edge. It also has only the Nextion connections at the lower right, and has the STLink connector to the left of the LEDs.

The original board from the same German guys is apparently now at v2.0, but I have not seen any pictures or the layout/schematic. I have no idea where you could buy one, and indeed the original boards were difficult to get hold of too.

[M7YTH]

Today I received an "legal and officially supported" mmdvm hat from BI7JTA. Unfortunately and disappointingly I am getting the same result. I can receive YSF from the pistar but it does not receive anything I transmit from the FT1D.

I have reported this back to the author of the firmware on Github.

M7YTH check out this info I dug up.

https://hb9uf.github.io/gr-ysf/
( I realize it looks like a sketchy link)

It might be worth it to bust out a Linux box or a livecd that has the capabilities of running GNURadio and getting it to run.

And then capture the signal from your radio and make sure its sending that "sync word" 0xd471c9634d, as that seems to be what the MMDVM_HS firmware is looking for when it comes to YSF.
https://github.com/juribeparada/MMDVM_H ... ines.h#L31

KE7FNS, thank you for the link to that gr-ysf program. I have download and compiled it as suggested in the hope that it would yield the kind of information that you refer to. I managed to get it up and running as per the author's instructions and I see the spike on transmit. I have centred the radio transmission on the channel as described in the "Getting Started" guide. At this point it says that I should be seeing "FICH packet dumps" in the console and hearing the decoded audio, but I am getting get nothing. I will probably contact the author for further advice.

[M7YTH]

I downloaded sdrangel but its a pig to compile. Struggle with it for a while but decided life is too short.
Have decided to return the radio to the seller while I still can.

[M7YTH]

Just perhaps a final note. Before I sent the radio back, I took a bit of time to familiarise with gnuradio and had another play with gr-ysf. I found that there are a number of disabled output files including raw data from various stages which can be enabled as required. Turning these on individually allowed me to determine data was being received from the gr-osmocomm module that handled the RTLSDR. This was getting past various filtering and transformation stages up until it reached the YSF decoder, but there was nothing coming out of the YSF decoder module. The raw data in the files up to this point was random and contained nothing useful like call-signs. At the entry point to the YSF decoder the data was quadrature decoded and contained only instances of 00's, 01's, 02's, 03's. However, the data being passed to the YSF decoder was evidently not being understood. Given that the signal was spot on centered as indicated and the signal strength within reasonable bounds, it can only be concluded that the Fusion encoding on the FT1D was somehow different enough not to be understood by the decoder, although evidently two local repeaters had no trouble with it. I don't really have any experience decoding packets so can only speak in very general terms. Is the decoder (in both gr-ysf and pistar) missing something or is the data garbled? I have no idea. Radio has gone back now so I guess that brings the discussion to an end!