Hello Tom,
Thanks for the reply. I appreciate the help.
Yes I can do a simple E Echo for the id-51.
I could not subscribe to DSTAR2 until this afternoon. At that time I used the Send UR field on the Dashboard and was able to subscribe and was able to listen to the QCWA Net. However, they could not hear me. This (early morning) I changed my Hotspot setting in my RT Systems Programming Software from 446.250 in both transmit and receive with no offset and Simplex selected in the pop up menu to 446.250 in both Rx and Tx and no offset and Dup+ selected in the pop up menu. For the first time this let me link to 1 Charlie and hear operators there. However, they still appear to be not hearing me.
After this change I could also subscribe to DSTAR2 or at least it appears that this was occurring in the logs.
Thanks for note on pi-star DMR hotspot being on at same time. I believe I can turn off the DMR+ network and apply the settings when I want to work with the DSTAR hotspot. This is the connection that uses the quad net server.
I'm still stumped about no one hearing me transmit but it could also be a function of the time (very early morning) and It could be that the one or two stations I hear were adjusting things also. I could see their Id on the Dashboard but I cannot see mine. Am I supposed to?

Thanks again for the help. Any further tips will be appreciated greatly.
73
Dale?
--
Dale L Puckett
K0HYD
Goddard, KS 67052
Member Society of Professional Journalists

Can you do a simple E echo from your 51?

Also you don't need to specify the module callsign if it's the same as your ircddb login.

And you can't link to DSTAR2. That "Link at startup" is for a reflector or repeater only. You'll have to subscribe to DSTAR2 after qngateway is logged into rr.openquad.net.

If you want to use DMR and your pistar hot-spot at the same time as your DVAP hot-spot, you should disable ircDDBGateway on you pistar. You shouldn't have multiple hotspots logged into openquad.net using the same callsign and IP.? I think in the pistar expert menu, clear the field that has "rr.openquad.net".

Hello Tom…

And everyone in the QuadNet2 USA IRC Network QnetGateway group.

Jeff, VE6DV, suggested that I try out this approach to DStar. It sounds like a challenge and fun so we jumped right in with both feet. I like the lightweight nature of this software.

I have a DVAP that I hadn’t used for several years because it would never work consistently on my iMac without restarting it every couple of hours. The Mac would go to sleep and when it did, bye bye DVAP During the past year however I have built up four or five raspberry pi computers and are using them for several radio related projects. It struck me that this would be a great application for one of my raspberry pi’s. I now have the 70 CM DVAP connected via USB to my Raspberry Pi 3B. I installed the latest Buster version of Raspian on the 3B.

I didn’t think I had any problems understanding and performing the configuration or the Building of the Qnet Gateway software. For the most part the logs look normal but I’m missing something because I can’t seem to link to one of the DSTAR Smart Servers and/or any Reflectors. Minor details… hi hi?

It’s has to be something simple I missed but I have been unable to find it. To help anyone that can point me in the right direction I have attached a text file containing the output of the tail of the logs for QnetGateway, QnetLink and QnetDVAP. I have also placed the details of my current configuration in this file! I hope this will make it easy to point me in the right direction.

I use an Icom ID-51A on the radio side. And program it with the RT Systems Programming software. I’m pretty sure I have it setup correctly. But I could have a mistake in there also. I also own an Anytone 868 and use it with Jeff’s multi-network configuration settings on Pi-Star installed on a ZumSpot. The combination is great!?

Do I have to turn off the DMR hotspot when I want to fire up the DSTAR DVAP?

Thank you to anyone who can help me get this system on the air.

73 de Dale - K0HYD







--
Dale L Puckett
K0HYD
Goddard, KS 67052
Member Society of Professional Journalists

As some know I use Crontab to switch reflectors.. The entire command string I won't reproduce here but just the functions

at time specified

Unlink,, && sleep 3 seconds && refresh && sleep 2 seconds && link

Well all but one of the commands worked perfectly that one would unlink. and hang

The Refresh command and 2nd sleep was added after problems arose with not re-loading the gateway file fast enough.?

(I tihnk That has been addressed but.. Well)

Best guess is one of the spaces (or more) were SHIFTED.. no way can I spot it but the computer did

I retyped all the space && Space bits after the unlink and? SUCCESS.

Oh the joy of learning a new (to me) Operating system.. that's one I'd have never seen unkess I used a special program I used to use on my Commodore 64 that showed me the ascii value of what was under the cursor.?

?

On Sat, May 30, 2020 at 06:56 AM, Tom Early wrote:

Glad you seemed to have fixed it. What was the trick?

Thanks for all the other info by the way. I am familiar with and have used all of those functions in the past.

Near as I can tell... my problem may have been caused by an issue with the gwys.txt file. This file is loaded into the SQL DB just prior to where the DB lock error was being encountered. So, on a hunch that a problem with that file might result is a lingering lock on the DB... I pulled a new copy of that file.

I can’t say for sure this fixed it. But I can say that I didn’t really do anything else that would have had any effect. As I mentioned... I did do a “git reset” just to make sure there wasn’t some source syncing problem. But I don’t believe that had any impact... nor do I know if that was the right command to do what I was seeking.

?

Glad you seemed to have fixed it. What was the trick?

Just to tie up some other loose ends...

• The shutdown command is the way to go. It will first try to stop all processes politely and then if they don't shutdown in a reasonable time, it will kill them with extreme prejudice. Use "sudo shutdown -h now" to stop the RPi, "sudo shutdown -r now" to reboot.
• Since QnetGateway programs run at root privilege, a database locked message may indicate that there might be a hardware problem, like a bad SD card. SD memory is definitely the Achilles heal of the Raspberry Pi.
• QnetGateway uses systemd. You have complete control over what it does and how it starts things. The systemctl command is your tool for controlling systemd. Most systemctl commands require root privileges. There are many articles on the Web on how to manage systemd using systemctl, like . After reading this article, see how much you understand of the install and uninstall sections of QnetGateway's Makefile.

As an example, you could stop your system without uninstalling it with:
sudo systemctl stop qngateway && sudo systemctl stop qnlink && sudo systemctl stop qnitap
or whatever module you are using. Note that this won't stop these programs from restarting on a reboot.
Then you could remove the database file and make sure it's gone:
sudo rm -f /usr/local/etc/qn.db && ls -l /usr/local/etc/qn.db
Then you would restart everything:
sudo systemctl restart qngateway && sudo systemctl restart qnlink && sudo systemctl restart qnitap

Note that the && is a bash feature that says, "if the previous command was successful, then execute the following command".

The one possible thing I may have done to make this work...

I noticed that prior to the command that generated the error... the program loaded the reflector list. Thinking that a corrupted reflector list might have inadvertently left the database locked... I pulled a new one.

And I did a git reset. That didn’t seem to do anything.?

On Fri, May 29, 2020 at 09:27 PM, Elden W7LDN wrote:

On Fri, May 29, 2020 at 09:24 PM, Elden W7LDN wrote:

Ok. There are apologies necessary here. In your prior instructions you mentioned viewing the qnlink log. I failed to catch that.?

Here’s what I found...

-- Logs begin at Fri 2020-05-29 21:09:12 PDT. --

May 29 21:09:24 zum2 qnlink[546]: CQnetDB::UpdateGW error: database is locked

However, I did proceed to take your recommended action to solve this problem by uninstalling and reinstalling things (way back in this thread). And the problem did remain. I could just wipe the whole deal and start with a fresh install of Raspbian.

Gah... perhaps you’re going to tell me that my tried and true method of restarting is not legit? I always do “sudo shutdown -r now”. Can that cause this sort of problem?

On Fri, May 29, 2020 at 09:24 PM, Elden W7LDN wrote:

Ok. There are apologies necessary here. In your prior instructions you mentioned viewing the qnlink log. I failed to catch that.?

Here’s what I found...

-- Logs begin at Fri 2020-05-29 21:09:12 PDT. --

May 29 21:09:24 zum2 qnlink[546]: CQnetDB::UpdateGW error: database is locked

However, I did proceed to take your recommended action to solve this problem by uninstalling and reinstalling things (way back in this thread). And the problem did remain. I could just wipe the whole deal and start with a fresh install of Raspbian.

?

Ok. There are apologies necessary here. In your prior instructions you mentioned viewing the qnlink log. I failed to catch that.?

Here’s what I found...

Ah... I hadn’t read this before we spoke today on the air. Very interesting. I feel the best shot of getting any problem fixed is getting it to where it can be reproduced. Virtually impossible to fix unless you can make it happen. I was totally planning on just forgetting about this. But considering the time and thought you put into it... I feel compelled to try to provide some useful info if I can. Particularly since I seem to be able to reproduce it here.

I will play with this a bunch more and see if I can glean any clues.

Debugging linux stuff isn’t my forte. I guess my first question would be.... can I prevent the QnetGateway stuff from auto starting? Then I could examine the system after the reboot... but before the normal startup processes. Then possibly I could start things up manually, one step at a time.

Okay, a couple of things: #5 in your process is not what I see. Both Safari on my mac and Firefox on my Linux laptop will timeout, both complaining about the unavailability of the Server soon after my ZUMspot starts the rebooting process. Both browser screens just display the "Server not found" error and neither ever refreshes when my ZUMspot is back, fully up and running. For your browser not to time out during the reboot process would mean that it's rebooting very quickly. Impossibly fast even.

For #6, the linked time is calculated by the query that the index.php file uses to extract data from the LINKSTATUS table in the /usr/local/etc/qn.db database. If it's showing the proper elapsed time since you originally linked (before the reboot), then that means either your system never rebooted or when it came back up, QnetLink was unable to clear that table in the database and you would see evidence of that in the qnlink log.

For #7 you didn't explicitly say, but I assume the webpage showed the proper link with the proper time as soon as you executed the link command. The #8 makes no sense because unlinking will clear the time, link and IP fields in the LINKSTATUS table. The only way it can be repopulated is with a linking command, it shouldn't ever go back to what it was before.

This is definitely "Twilight Zone" territory. It almost sounds like there's a phantom system running under your pi.

Finally, to address your question further down in this thread, there is no way data from a browser could end up back in the qn.db file. For one thing index.php opens the database read only, and all of the QnetGateway programs never connect to an HTTP stream.

To put it differently... perhaps leaving the browser open across the reboot would cause session variables to continue to live after the reboot. If the dashboard depends on session variables... perhaps... just a thought.

Seems odd... but the web browser that I’m leaving open across the reboot... is on an iPad. The iPad web browser is umm... not exactly standard. I wonder if it’s in any way possible that the QnetGateway software is loading any data from the cache of the browser? I mean otherwise... where would it be getting the data that is being displayed? This data is showing on a completely different computer on a browser that had never before loaded the dashboard web page.
?

On Thu, May 28, 2020 at 04:20 PM, Colby Ross W1BSB wrote:

I am unable to reproduce. ?Once I rebooted my Pi after linking to something, the page eventually went to page cannot be displayed. It did not refresh from this point. I had to manually refresh, at which time, it said “Unlinked”

?

Ok. Thanks for trying. Guess this is twilight zone territory.

开云体育

On Thu, May 28, 2020 at 10:07 AM, Colby Ross W1BSB wrote:

It could be his browser caching this information and not refreshing correctly.

?

I took all the recommended steps. Uninstalled, reinstalled. Checked that no auto connect was specified. This is still totally reproducible here.

And to test the browser cache theory... after the browser was showing the bogus info... (after rebooting with an active connection)... I loaded the status page using a completely different computer. The invalid info was there. This tells me it’s not a browser/cache problem.

Here are the steps to reproduce...

1. make a connection to a D-Star reflector
2. load the dashboard in a browser
3. once the dashboard shows you connected... reboot the Pi
4. leave the dashboard page alone
5. once the system comes back up... the dashboard page will refresh by itself... showing the bogus info
6. the “linked time” field will show a time span that goes back before the reboot
7. at this point... you can link to another reflector
8. when you unlink from that other reflector... it will again show the bogus link info

Don’t know what to tell you on this. Except I’d suggest following these steps precisely. I’ve run through these steps a number of times. All with the same result.