开云体育

Is there an equivalent of 30C on d-rats? A channel that has some consistent chat activity? Thanks, AB7RU

The past two days the area of Southeastern PA conducted the Limerick Generating Station nuclear power emergency drill. This takes place every two years (same as other nuclear plants). Part of this (a small part) exercise has been ham radio backup communication. We have been training on a few digital modes for emcomm here in Lehigh Valley PA; WinLink, FLDigi and primarily D-Rats. We are lucky to have outstanding DStar repeater support in this area with 5 repeaters in HT range of most of the area. The portion of the drill that ran Tuesday night was the "EOC Drill" where many municipalities and counties simulated their procedures. Ham radio manned the "RACES" radios inside EOC and our regular weekly training group formed kind of a net and demoed D-Star and D-Rats to FEMA. We focused on the ability to send email using the radio. We have a full time mail server (basically another instance of D-Rats) connected to one of the repeaters. This provides the functionality of WinLink without a local RMS node (which do not exist in this region) and without the requirement to use HF for WinLink (which we don't really support for emcomm except in a relay situation as required). The Wednesday portion of the drill was the "Shelter Drill" where we simulated relocating people (and pets) out of the impacted area into ours (we are far enough away to be an evacuation reception area only). We mobilized our club trailer and again used D-Star and D-Rats. In this instance we sent email from the trailer (no internet) to the mail accounts of two PEMA and one FEMA observer. The FEMA observer got a formatted ICS 213 form on her iPhone right there and replied, witnessing the whole operation. I believe they were pretty impressed, and were taking notes on the whole thing for their report. So D-Rats pretty much nailed it in an official FEMA/PEMA operation. One thing that was kind of funny/not funny: BOTH nights the FEMA observer asked if we have any young people in ham radio. They said in their observations the vast majority of hams they see in this kind of thing are old folks. We did summon our "token youth" who was at this drill to demonstrate we will not actually become extinct in a few years.

Anybody know what the "sniffer" messages mean you see at the bottom when you or someone else is passing traffic? Specifially stuff such as (S:4 L:1) etc? I'm guessing some kind of packet stuff with sent/lost. But that's just a guess. Thanks.

Hello Group, I am interested in running D-RATS without an Internet connection. I have an IC-9700 connected to a PC using the Data port and the data cable. I have set a port for the IC-9700 and when I ping all stations, the radio transmits, which is a good sign. I have several ratflectors configured in D-RATS, such as gaares.ratflector.com. The radio is connected to the W4DOC repeater, module C, and I have configured all Connector and DV settings as explained in this forum. The question is as follows: Can I connect through the repeater to ratflectors using an RF-only port (ie, no internet on the host PC). Our Internet connection has gone down many times (tree limbs cutting the fiber optic during a storm), and it would be nice to have chat functionality via D-RATS in that scenario. What am I missing? When I post a message to the D-RATS chat under this condition there is no response. Thank you! Facundo

What is a source to start from scratch? I have renewed interest because of this grouThank you es 73, Doc - K?HTF -- 73 & Travel safe and God bless!! Tom "DOC" Gruis, K?HTF, Ed. D., Gideon and Mason. IRLP 7793, EL 50511, All* 43675, DMR 3119191, D*, and NXDN 1206 GMRS WQNU766, Part 15 Beacons D. ? k0htf@.... gruis.net “Vergessen Sie bitte nicht, die Antenne zu erden!” (Please do not forget to ground the antenna!) GOD BLESS AMERICA!!

Is there way to block a user from a ratflector? We have two operators from Portugal sending weather messages to us almost continuously. That unneeded traffic makes it easy to lose track of local traffic. I've filtered them in DRATS, but would like to block them from the ratflector.

Python3/GTK3 Progress: The d-rats client program in my python3_tyw branch of https://github.com/wb8tyw/D-Rats seems to mostly work on both python3 and python2 now. The map display is not working. I made that change and announced it a while back, but have not seen any feedback. I am now testing it using the msys2.org mingw64 packages of python in addition to anti-x linux. mysys2.org has fixed the broken package that was preventing some windows packages from working. Because I am using the mingw64 packages of python, the shebang launching of d-rats does not work. My next change to my frok will probably to start disabling python2 support. The main reason for that is that I have been refactoring the map routines into their own directory, and if I nest it under the d_rats directory, I can not get the module resolution to work with python2. I have been documenting the refactoring / port of the Map Display with at https://github.com/wb8tyw/D-Rats/wiki/MAP-Display-Part-2 It is now functional for displaying the map for any coordinates that I put in. I have not yet connected that refactoring back to the d-rats client program. I am still testing it standalone. I want to be able to test plotting stations on the map before I merge it back in. Hopefully my wiki articles can help get other programmers as this is a very complex program. And again, I am still learning both d-rats internals and GTK programming. 73, -John, wb8tyw

Is it time to create a group managed d-rats.github.com project? A group managed GitHub project will allow multiple community members to be the administrators of it similar to the [email protected] mailing list. I have no idea how the groups.io d-rats group is managed, but it seems to work well enough, if they could also do the administration of the GitHub project. This project would have multiple d-rats related repositories on it. This could have one or more data repositories with urls or other data that could be downloaded from the d-rats program instead of being hard coded and sometimes out of date like the ratflector list. The GTK 3 library wants to have the d-rats main be an "application" that has a unique application identification. They prefer to use reverse domain name notation, with a GitHub project that would be something like "com.github.d-rats.client". The reason for adding the ".client" is because we may want the form editor to be able to be run as a standalone program, and the repeater is also a standalone program, so would have different application identifications. 73, -John, wb8tyw

I am having trouble getting my D-Rats application to connect to the to the default ratflector in the software download. I downloaded D-Rats, followed the tutorial to set things up, my call, name, gps, and so on, and am using the internet connection to attempt to connect. The message I get when it tries to connect is " (Unable to connect, error 100061 " connection refused'))". I do not have any other rat reflector info to put in to try to connect to a different one, as it appears that the D-Star Info website is down and has been for a day or so, which has the only other list that I know of any additional ratflectors to try to add to the list. Any advise or direction on something I may have missed in the set will be greatly appreciated. This is on a Windows 7 machine. Thanks. David...W4DCA

When trying to test the map source editor with my work in progress port, I discovered that it is no longer working with the original d-rats program. The USGS has both changed the URL used, they have changed the entire way of querying the data. It looks like now, just query the data for the sites list, I have to pass the longitude and latitude of the current map boundaries. I am not sure how that map data was used in the past or how it should work in the future. Can someone explain how map sources and overlays are supposed to work? 73, -John wb8tyw

Hello all, I have pushed up a number of updates to my python3_tyw port. The main code is still not working on python 3 yet for me. The d-rats_repeater.py works for me on Anti-X/Linux using python3, but will not yet start in Windows msys2 mingw python3. The d_rats.config is now working, with Python3, and even Windows msys2 mingw python3 where the audio tests even worked. msys2 mingw can not use the shebang of /usr/bin/python python3 -m d_rats.config I discovered that the formgui.py unit test was not working with all of the forms. That has been fixed. python -m d_rats.formgui forms/hics260.xml or python -m d_rats.formgui forms/hics260.xml The formbuilder module also needed some fixes to work. I have not fully tested the form functionality, so there may still be some bugs there. I have additional diagnostics enabled. Anywhere a broad or bare exception is being caught, is somewhere that needs to be fixing, so all of them that I find are being logged. 73, -John

My 7100 started acting strange with D-Rats (039 version). Over the USB connection for data when I transmit chat the radio repeatedly keys up. First transmission after changing a connection or something is usually normal...keys up, sends, shuts down. Subsequent chat keys up like 5 times and appears to keep sending the same thing. It did not do this awhile ago. The 7100 is not my normal D-Rats radio ( I use an 880H with the orange cable) so hard to say when this began....new version of D-Rats, some kind of windows update...not sure. My feeling (guess) is there is some kind of buffer trying to send again and again. I plugged an orange cable into the 7100 and it works exactly like my other radios....keys up, sends data, shuts down. A member of our Thursday D-Rats group is having the exact same issue with an Icom 9700 over USB. Otherwise I'd think it was just my computer. Any ideas? Anyone else see this? ONLY on the USB conection, and ONLY on D-Rats DV data...JS8Call, FLDigi....all that works perfect over USB.

Just pushed an update for the d_rats/geocode_ui.py to the python3_tyw branch of my fork. The module now detects if the python geopy module is available, so callers can be modified to work if it is missing. Code using the Assistance class will need to be to changed check if the geocoders property is not None. This will allow running on platforms that do not supply the geopy module where the user does not want to trust PyPI. This module has been converted to use the python logging module. I just noticed that the name for the unit test logger is wrong, I will fix that in a future commit. Tested on Windows with msys2 python 3 that does not have a geopy module and also on anti-x linux with python2 and python3. 73, -John wb8tyw@...

Hey Everyone, I saw this today from the Debian bug tracking system and the hits of start of removing GTK2. Read the details here as it seems that even GTK4 is just around the corner. Does anyone know if all this GTK3 work will be mostly compatible with GTK4? --David KI6ZHD Your message dated Wed, 13 Oct 2021 20:23:02 +0000 with message-id <E1makmE-000104-0H@...> and subject line Bug#967595: fixed in libzia 4.32-1 has caused the Debian Bug report #967595, regarding libzia: depends on deprecated GTK 2 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact owner@... immediately.) -- 967595: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=967595 Debian Bug Tracking System Contact owner@... with problems ForwardedMessage.eml Subject: libzia: depends on deprecated GTK 2 From: smcv@... Date: 08/04/2020 03:52 AM To: maintonly@... Source: libzia Severity: normal User: pkg-gnome-maintainers@... Usertags: gtk2 oldlibs Control: block 947713 by -1 This package has Build-Depends on GTK 2 (libgtk2.0-dev), or produces binary packages with a Depends on GTK 2. GTK 2 was superseded by GTK 3 in 2011 (see <https://bugs.debian.org/947713>). It no longer receives any significant upstream maintenance, and in particular does not get feature development for new features like UI scaling on high-pixel-density displays (HiDPI) and native Wayland support. GTK 3 is in maintenance mode and GTK 4 is approaching release, so it seems like a good time to be thinking about minimizing the amount of GTK 2 in the archive. GTK 2 is used by some important productivity applications like GIMP, and has also historically been a popular UI toolkit for proprietary software that we can't change, so perhaps removing GTK 2 from Debian will never be feasible. However, it has reached the point where a dependency on it is a bug - not a release-critical bug, and not a bug that can necessarily be fixed quickly, but a piece of technical debt that maintainers should be aware of. A porting guide is provided in the GTK 3 documentation: https://developer.gnome.org/gtk3/stable/migrating.html Some libraries (for example libgtkspell0) expose GTK as part of their API/ABI, in which case removing the deprecated dependency requires breaking API/ABI. For these libraries, in many cases there will already be a corresponding GTK 3 version (for example libgtkspell3-3-0), in which case the GTK 2-based library should probably be deprecated or removed itself. If there is no GTK 3 equivalent, of a GTK 2-based library, maintainers should talk to the dependent library's upstream developers about whether the dependent library should break API/ABI and switch to GTK 3, or whether the dependent library should itself be deprecated or removed. A few packages extend GTK 2 by providing plugins (theme engines, input methods, etc.) or themes, for example ibus and mate-themes. If these packages deliberately support GTK 2 even though it is deprecated, and they also support GTK 3, then it is appropriate to mark this mass-filed bug as wontfix for now. I have tried to exclude these packages from the mass-bug-filing, but I probably missed some of them. Regards, smcv

Hello All, I just pushed a test program to my test fork. The code from it could be easily added to the main branch. Details are in: https://github.com/wb8tyw/D-Rats/wiki/Internationalization Hopefully we can get some good translations now, and get the international code actually working. This also demonstrates the logging api that I am planning on replacing the printlog() calls with. 73, -John wb8tyw@... / wb8tyw@...

Hello all, I just posted some updates to https://github.com/wb8tyw/D-Rats/tree/python3_tyw Most of these are minor fixes to silence pylint and plance warnings. I also have not synced it up recently with Maurizio's master branch. The mapdisplay is still not usable, and python3 still only works for the ratflector. The mapdisplay.py unit test is now partially working, and displaying the map longer. I have a local version that even more somewhat works but is just not good enough. So much has changed from pygtk 2.x to the gtk 3.x that is currently supported, that it looks like a major re-write is going to be needed. And for that I am going to have to learn gtk 3 programming more, so I am going to be working on a refactored mapdisplay3.py module as I learn how to make it work. I am also starting to try to test this using Windows 7 and msys2 mingw 64 bit environment. I hit a bug in msys2 mingw that will keep some Windows components from being tested until an updated package is available. https://github.com/msys2/MINGW-packages/pull/9752 I spent a lot of time today trying to find a workaround for that issue before filing a ticket, and was surprised at the fast response by that team. I chose msys2 for windows testing as it has a package installer that checks signatures, so that an installation can be setup. At the present time, I also have a 32 bit windows 10 system to test with. I have not found a quick to install python 3.x for it, as it seems that 32 bit windows 10 support is being abandoned quickly. It is an Intel Compute Stick. In my fork, I am going to start removing the utils.printlog() related routines in favor of a system based the python logger module, which does the same stuff with a lot less work to maintain. The python logger module can be used for both the current errorlog and it eventually can be used for logging events for the d-rats event window. This is done by adding custom logging levels, and then an event log handler can have a list of what to display. I plan to be testing this re-write in small steps / commits in my fork, starting with a "hello world" type program and then adding functionality in steps. I also want to start looking at getting the gettext internationalization actually working in that module. https://github.com/wb8tyw/D-Rats/wiki/MAP-Display 73, -John wb8tyw