No RF receiving when mmdvm_hs_dual used with RT80

MMDVM_HS Hat hardware
Post Reply
DG4EK
Posts: 3
Joined: Thu Feb 21, 2019 3:06 am

No RF receiving when mmdvm_hs_dual used with RT80

Post by DG4EK »

Hi,

I'm using Pistar running on a raspi-3B having a mmdvm_hs_dual_hat board V1.3 mounted.
Its running in gateway mode but there came up problems
as I got two new cute Retevis RT80 (brand new model).

Hopefully the community can help to solve them, thank you:



1.)
The mmdvm gateway works fine on RF if I use my RT3 or RT90.

But using the new Retevis RT80 I mostly cannot get into the gateway by RF. The MMDVM ignores 99% of
calls to the Gateway which have been tried using both RT80.

I made frequency calibrations using the mmdvmcal function and also BER optimisation.
It came out that the MMDVM RX was about 120Hz too high.
I adjusted the offset by setting it into "RX-offset"
in MMDVMHost menu. Anyway, no effect but BER tested
in mmdvmcal with ~0.17% !

As a last desperate test I tried the RT80s to get in touch with a local DMR repeater (20km from home)
Both worked fine on the parrot.

After all: Strange, isnt it?

Anybody out there telling me how to solve that?
It seems to be pretty clear that this must be a problem at the mmdvm's
(I tried a V1.0 and a V1.3 board, same behaviour).




One of my ideas is that the RT80s does a little too much deviation but
unlike at the RT3 and RT90 deviation index cannot be adjusted at the RT80.


Desperately looking for any idea... :cry:

Thank you!

73 de DG4EK,
Peter

-------------------------------------------------

Friday, 02/22/19
Additional information:


In the last hours I practized a little bit more with the RT80 and
the MMDVM. It came out that the MMDVM does not recognize RT80s TXed DMR signal.
Therefore MMDVM does not send an answer to the RT80 and no connection can take place.

I'm pretty sure about this cause if some signal from the net is put to RF
then RT80 takes this as an recognition of its own RF signal (of cause the
RT80 has to TX at the same time when MMDVM sends it signal from the net).
If that happens, then MMDVM accepts further RT80 transmissions and put them into
the internet.

Thats the reason why I got some random connects during daytime.

If all TGs are quiet (as they are mostly during night time)
then no connect is possible.


Any idea what I can do ?

Thanks a lot
73 de DG4EK, Peter
DG4EK
Posts: 3
Joined: Thu Feb 21, 2019 3:06 am

An idea what could be the problem ->No RF receiving when mmdvm_hs_dual used with RT80

Post by DG4EK »

I saw that the RT80 uses 8 digit DMR IDs.

So the "normal" 7-digit IDs will be enhanced with a leading zero.
Are they send out as 8 or as 7 digits?

For example my 2625642 to 02625642.

Could this possible confuse Pi-Star?

Unfortunately I'm not a programmer and there is
no way for me to inspect the transmitted start-repeater-mode-datastream.

Only an idea....

Still a miracle what is going wrong... :?


73
DG4EK, Peter
DG4EK
Posts: 3
Joined: Thu Feb 21, 2019 3:06 am

Re: No RF receiving when mmdvm_hs_dual used with RT80

Post by DG4EK »

Story is still going on.

No solution yet but some more ideas as I determined the MMDVM source code.

As I told earlier it isnt possible to connect the MMDVM using the Retevis RT80 so I
had a look into the pi-star log (admin -> protocol).

It gives an error message when I try to connect:

"Invalid Downlink Activate received from 0"

In the MMDVM_Host firmware source this message can be located inside
the file DMRControl.cpp where IDs (length) and white/blacklists etc. are being validated.

So my first idea was to have a look to the ID which the RT80 transmits into air.
There I found that it uses 8-digit IDs which are not standard (RT80 adds a leading zero).
But ....going on in code analysis I saw that this cannot be the error. :x

So further investigations have to be done.....

---------------------------

Anybody out there who is a C++/C# professional to re-engineer the masses
of code? :D

I guess following the error message back in the code it must be
possible to find the problem....


Thanks a lot and
73
de DG4EK, Peter
Post Reply