开云体育

I am wondering if this means anything. Apr 10 19:00:55 dstarrepeater qnrelay[372044]: Reading file /usr/local/etc/qn.cfg Apr 10 19:00:55 dstarrepeater qnrelay[372044]: module_b = 'mmdvmhost' Apr 10

I have been watching qnetgateway while connected to ref030 C Apr 10 21:34:28 dstarrepeater qngateway[372108]: Inactivity to local rptr module B, removing stream id 7903 Apr 10 21:55:10 dstarrepeater

Everything is still in the correct spot. I just pointed to the source to see if maybe that was the problem. No echo doesn't come through the repeater. Here is what I get for echo. Apr 09 21:30:16

Does Echo work? It might also be helpful to post your qn.cfg file. You've moved stuff from the standard locations to /root/QnetGateway. How come?

Apr 08 23:04:51 dstarrepeater qnlink[129407]: sending File:[/root/QnetGateway/announce/connected2network.dat], mod:[B], RADIO_ID=[WELCOME TO QUADNET? ] Apr 08 23:05:27 dstarrepeater qnlink[129407]:

Apr 08 22:17:33 dstarrepeater qnlink[124504]: #Gateways: /usr/local/etc/gwys.txt=7001 Apr 08 22:17:33 dstarrepeater qnlink[124504]: read 62 indicies from /usr/local/etc/index.dat Apr 08 22:17:33

Hi Ryan, I think I might know what's going on. Could you please try the "rc" branch: sudo make uninstallbase && sudo make uninstallrelay make clean git checkout rc git pull make base && make

So I am sending I command. I am getting this: Apr 08 02:37:12 dstarrepeater qnrelay[5157]: DEBUG: ProcessMMDVM: unusual packet len=24 Apr 08 02:37:13 dstarrepeater qnrelay[5157]: Read error on

So, I am coming to the conclusion that there is something different from MMDVM and DStarrepeater. It will take my commands. But no matter what I do. I can not get rid of this. Apr 08 02:12:55

Well, I found version 1.05 and ran that, now the serial number is back and it runs fine with qnet, so the 1.07 messes up the s#. I upgraded as it randomly crashed with pistar, and 1.07 seemed to fix

The fact that you see a garbled SN# string means that your DVAP has been updated to FW 1.07 Did you ever upgraded it yourself? Maybe you bought it second hand and the original owner updated it Sent

Hi there. Actually, before doing that update with that program, I could read the SN# of the the dongle. After the update, the SN# was all garbled. I think the update obviously shifted the location

Hi Robert, That link does not seem to work. When I run updater, it displays the serial number as AP.... and then some non ascii characters. Would appeciate if you could test that link, it ceratinly

It's me again, Robbert / PA3BKL, replying to my own post. After THINKING that I had bricked my red DVAP during a FW update, I left the unit disconnected for about 10 mins. I just tried to flash it

Here is a solution: Download this program from here: http://www.dutch-star.eu/software/download.aspx?name=/dongle/DvapUpdaterSetup107.zip Run the program, and click the "Read DVAP Info" button BUT

Hi Tom, You hit the nail on the head... the serial number in the DVAP is corrupted, that is why DVtools doesn't want to talk to it either. Luckily pistar doesn't worry about it. I guess I could try

Hi Horst, Please don't give up, at least just yet. Colby and I would like to get to the bottom of this... I fired up my DVAP and it is on FW version 1.7 as well. The very next message you should

The "[108B blob data]" is probably the error message we want, but it looks like qndvap is reading some binary data instead of an ascii string when trying to read the serial number. It might be useful

Before you give up, please show me the contents of your qn.cfg file. If you type cat qn.cfg you can then copy and paste it here. If it works in pi-star, it should work with QNetGateway as well, which

Hi Colby, Did that, but it basically showed the same thing, no extra info that I can see. When I restart the module, the blue and red led flash for a second or so, and then it stops. It looks like it