[DSTAR_DIGITAL] Re: The big DStar breakthrough needs to be ...
Hi John, These are good comments and I generally agree with them. I'll add a few thoughts of my own here... 1) a 'glass cockpit' style of interface - an LCD that is either itself touch sensitive or is surrounded by softkeys, or both. Note that the IC-2820 already has a large, dot-matrix LCD and softkeys. I was a bit disappointed when I purchased my 2820 to see that, unfortunately, they don't make better use of it. Still, it indicates that at least someone at Icom is thinking about UI design, even if -- to date -- the execution still leaves a lot to be desired. This is against the trend of physicially smaller and smaller radios, but look at some of the current smart phones. HT's don't have to fit in a shirt pocket Also keep in mind that most mobile rigs today still have segment-style displays; it's only the higher end radios with dot-matrix LCDs. On something like an ID-800, the *size* of the display is still plenty big (for most people) -- most since it's not dot-matrix, the information available on it is quite limited. Additionally, the information you might need while setting up/programing a radio is different than that needed while just operating it, so it's reasonable to use big fonts with limited information for typical usage modes and then shift to small fonts with more information for setup/programming... where the user is presumably stopped, can get up nice and close the radio, etc. 2) a repeater/gateway database that is EASILY downloaded and updated via the internet - wifi too so you can do this in your driveway; Agreed... I've often thought the same think just for regular old 2m/440 repeaters. In fact, I suspect you could even sell a standalone widget for something like the IC-2820 that contains a repeater database, monitors the GPS feed, and then (at the touch of a button or something) can be set to re-program, say, a particular bank of memories to the 10 (or whatever) nearest repeaters geographically. Such a widget is very straightforward and reasonably inexpensive to build -- it's just your typical microcontroller plus glue logic and an SD card slot, but of course writing the software and then entering the databse itself is time consuming. There's more, but this is enough to be food for thought. I suspect the main problem here is the relatively low numbers of D*Star users vs., say, Windows Mobile users -- most of what you're looking to do here is readily done with a Windows Mobile-based smart phone, which typically have a 320x240 or 640x480 touch screen display, Bluetooth, WiFi, and GPS built in, and cost less than $500 (often half that...). So long as you stay within range of cell towers (which is nintey-something-percent of all U.S. interstates), you can run instant messaging programs, play back podcasts, surf the Internet, read RSS things, etc. -- very, very powerful. Hence, where D*Star can really shine is for those small percentage of people who want voice and data communications outside of cell service areas, and I suspect that percentage is probably well under 1% of the population. ---Joel
[DSTAR_DIGITAL] D-PRS Interface TCP Reconnect WAS: Re: W0CDS D-PRS
Pete, It seems like if I specify a TCP Port for D-PRS Interface to connect to (I'm talking TCP serial port here - as in connecting to DVTool), that D-PRS Interface will only try once to connect to the TCP port when the application is first launched. Is there anyway I can talk to you into a new version of DPRS-Interface that will retry the TCP serial port connection if the TCP server is not available, or if the connection is lost? A retry of once per minute or so would be great. I've added code to D-STAR Hot Spot to make a TCP server available that will stream out the slow speed (DPRS) data to your D-PRS Interface application. My concern arises in a situation where D-STAR Hot Spot and D-PRS Interface are launched automatically on Windows boot-up. If D-PRS Interface happens to launch before D-STAR Hot Spot, and Hot Spot's TCP server is not ready yet, that D-PRS will never make a connection. A TCP connect retry from D-PRS Interface would cure this issue. Thanks! Mark (KB9KHM) --- In dstar_digital@yahoogroups.com, Peter Loveall p...@... wrote: --- In dstar_digital@yahoogroups.com, Jon M. Hanson jon@ wrote: Is something wrong with W0CDS' D-PRS gateway to the Internet? I thought I heard a couple of position reports come out of my radio acknowledged by W0CDS but they didn't appear to make it out to the APRS network. A simple explanation of the D-PRS IGate on the gateway: The D-PRS IGate monitors the repeater to gateway bit stream looking for the Icom low speed serial information. This information is carried in unprotected form via RF and the bit stream format is not altered going to the gateway. If Icom GPS information is seen AND it is in the proper format (see http://www.aprs-is.net/dprs.aspx) AND there are no bit errors, the D-PRS IGate will translate the received GPS information into an APRS packet and send it to APRS-IS. For the bit stream to be seen by the gateway, you must have the repeater in RPT1 and the gateway in RPT2. For normal operation, we recommend you have CQCQCQ in URCALL. For proper format to be gated to APRS-IS, review http://www.aprs- is.net/dprs.aspx and configure your radio accordingly. The gateway does not acknowledge transmissions (nor does the repeater). What the repeater (and gateway) does is tell you by different responses whether your RF header (contains both forward error correction and error detection) was received properly or not (basically, it is more detailed than that). There is no indication of bit errors in the low speed data portion of the transmission. Individual beacons (never beacon more often than every 5 minutes on a repeater and never beacon if you are active on voice) quite often will have at least one bit error which will invalidate the position report to the D-PRS IGate. If you are using an amplifier with a hand- held, you might also be chopping the RF header preventing your bit stream from making it to the gateway. Icom has their radios continuously send GPS information (GPS or GPS-A mode) when you are talking which greatly increases the chances that at least one report will get through error free. Hope this helps. 73, Pete Loveall AE5PL
[DSTAR_DIGITAL] D-PRS Interface TCP Reconnect WAS: Re: W0CDS D-PRS
Pete, I should also mention that this future version of D-STAR Hot Spot will only send slow speed (DPRS) data received from the attached RF receiver to D-PRS Interface. Slow speed data embedded in a DV stream received from a connected gateway or reflector will NOT be sent out the TCP port to D-PRS Interface. I've added this functionality because mobile D-STAR Hot Spot users who transmit DPRS data do not show up on the APRS-IS network, even when Hot Spot is connected to a repeater with a G2 gateway running D-STAR Monitor. This is because data forwarded to DPlus from a connected D-STAR Hot Spot is not passed to D-STAR Monitor. Thus D-STAR Hot Spot must have it's own means of passing DPRS data to the APRS-IS network, rather then relying on the connected gateway. Rather than build my own APRS-IS client inside of D-STAR Hot Spot, I figured your D-PRS Interface software would fit the bill perfectly. Initial testing shows that the TCP connection between D-STAR Hot Spot and D-PRS Interface works great! Mark (KB9KHM) --- In dstar_digital@yahoogroups.com, kb9khm kb9...@... wrote: Pete, It seems like if I specify a TCP Port for D-PRS Interface to connect to (I'm talking TCP serial port here - as in connecting to DVTool), that D-PRS Interface will only try once to connect to the TCP port when the application is first launched. Is there anyway I can talk to you into a new version of DPRS-Interface that will retry the TCP serial port connection if the TCP server is not available, or if the connection is lost? A retry of once per minute or so would be great. I've added code to D-STAR Hot Spot to make a TCP server available that will stream out the slow speed (DPRS) data to your D-PRS Interface application. My concern arises in a situation where D-STAR Hot Spot and D-PRS Interface are launched automatically on Windows boot-up. If D-PRS Interface happens to launch before D-STAR Hot Spot, and Hot Spot's TCP server is not ready yet, that D-PRS will never make a connection. A TCP connect retry from D-PRS Interface would cure this issue. Thanks! Mark (KB9KHM)
[DSTAR_DIGITAL] D-PRS Interface TCP Reconnect WAS: Re: W0CDS D-PRS
--- In dstar_digital@yahoogroups.com, kb9khm kb9...@... wrote: It seems like if I specify a TCP Port for D-PRS Interface to connect to (I'm talking TCP serial port here - as in connecting to DVTool), that D-PRS Interface will only try once to connect to the TCP port when the application is first launched. D-PRS Interface is a Windows GUI encapsolated javAPRSSrvr (APRS server software). The TCP port interface in javAPRSSrvr is specifically designed to connect to a reliable (always there) TCP port that presents pure serial data. Because this software is written in Java, there is no ability to know why a connection goes away other than it was terminated (what we give up to be able to be platform independent). I believe the assumption that a Windows GUI progrm can be started after the TCP port becomes available is a valid one. The software that uses the TCP port code relies on the the interface to either be there or not at startup and would require a major rewrite of more code than the TCP port code. 73, Pete Loveall AE5PL
Re: [DSTAR_DIGITAL] Re: The big DStar breakthrough needs to be ...
My response is in relation to U.S. regulations, other countries may have stricter or looser regulations. I don't believe D-STAR should be limited to the lowest common denominator. Each radio operator should be responsible for operating his/her station under the regulations that govern their station. The regulations lag technology, so sometimes we have to look at the intent and apply it to the new technology until it is clarified. Several of these Internet activities probably fall under the content rules that were established for packet radio. On Sun, Dec 28, 2008 at 12:55 PM, Bob McCormick W1QA ya...@w1qa.com wrote: Things that are unacceptable: - booking an airline reservation at a web site How is this different than ordering a pizza over an autopatch (which the FCC has specifically allowed)? - sending/receiving email from your company's servers This is a touchy one, but you can call your office over an autopatch to invite a co-worker to lunch, as long as you don't facilitate your business in the process. So reading email, of a non-business nature would probably be OK, you certainly couldn't email your boss to report on a project or a subordinate giving them tasks to perform. - general Internet web browsing (because a lot of it has commercial content) Again, it all depends but I think most people are more comfortable with only access to a limited number of sites. -- John - K7VE
RE: [DSTAR_DIGITAL] Re: The big DStar breakthrough needs to be ...
John Hays K7VE replied to my recent posting: John: I neither want to hijack this thread ... or get too deep into this as there is most certainly a lot of grey (or is it gray?!) area. Probably a good discussion but one that will in the immediate term probably never reach a solid conclusion as so much is open to interpretation. In the end - it is certainly up to each licensee, control operator, etc. to interpret what regulations apply, enforce them and be held accountable. I certainly didn't want to imply that D-STAR should be limited to the universal lowest common denominator for world-wide regulations! Elaborating on this: Things that are unacceptable: - booking an airline reservation at a web site How is this different than ordering a pizza over an autopatch (which the FCC has specifically allowed)? I don't know / have not heard about the FCC specifically allowing ordering a pizza over an auto patch or similar activities. If that is the case (acceptable) ... OK ... still - as a control op I would frown on it. I would consider booking an airline ticket a business transaction and something that shouldn't be done over Amateur radio. (If the FCC regs in the US actually allow then OK - I need to get a cite so I can be up-to-date with the rules.) But maybe more importantly - that airline reservation over the Internet would probably make use of HTTPS (SSL) encryption ... and my personal opinion would be HTTPS traffic probably shouldn't be allowed (as its encrypted). What do you / others think on that one (SSL)? - sending/receiving email from your company's servers This is a touchy one, but you can call your office over an autopatch to invite a co-worker to lunch, as long as you don't facilitate your business in the process. So reading email, of a non-business nature would probably be OK, you certainly couldn't email your boss to report on a project or a subordinate giving them tasks to perform. Ayup. Agreed. And then there is the question about even sending information over the Internet (and D-STAR) in clear text. Let's say you have a POP3 account (whether work or otherwise). And you use the POP3 protocol which will send your username and password to the POP3 server in clear text. Anyone listening as the man in the middle now has your access info ... FWIW - at the $dayjob the only way to access the mail server externally is via SSL. (No IMAP or POP3, etc.) - general Internet web browsing (because a lot of it has commercial content) Again, it all depends but I think most people are more comfortable with only access to a limited number of sites. What I didn't include in my original reply ... but I was thinking: This problem: limited number of sites is much like the issues libraries and other public places that provide Internet access have. Many want to limit the reach of what sites folks can access. (Here I am thinking of blocking sites that would be considered socially unacceptable.) In any event - we have a 23cm DV + DD on one of our local D-STAR systems but the gateway is not yet connected to the Internet. Once it is ... there is less than a handful of people that have the requisite rig to use D-STAR DD. I think for the time being, in our area, the minimal interest and high entry cost for the ID-1 radio really diminishes any concerns I have about Internet access over D-STAR. Bob W1QA
[DSTAR_DIGITAL] Whats to be regulated... for what it's worth
We have so many self appointed lawyers in our amateur radio community you're always going to have individual interpretations of what is and isn't allowable. We are a self regulating service but that doesn't give any operator the right to dictate what others do because they interpret the rules differently unless they are the radio trustee. A part of the problem is that regulations don't keep up with technology. To say you can't go to a web site because it has commercial content to me is a bit of a stretch of calling your internet browsing commercial. Since the FCC allows you to order a pizza over the phone what difference would it be if you ordered the pizza through their web site? So this brings up the BIG question that were not suppose to encrypt our transmissions on amateur radio. so does this mean we can't visit an https: site? Some would say no you can't because it's encrypted. but then what if that site is a D-STAR Registration Site and all your doing is amateur radio related activities? I would say technically no you couldn't access it via an amateur digital radio modes, but would I? Most likely I would say yes I would because it involved an amateur radio activity. So now were involved in support of a major disaster and all normal lines of communications are down but by some means an amateur radio D-STAR site has survived with its internet connectivity intact. Can we pass emergency traffic that is surely going to help some commercial entity sell their wares, whether it is medical, construction, or food supplies. I would most certainly browse the internet on D-STAR and look for suppliers. Even if only to find emergency generators, snow shovels etc. So I personally would say Just Do ItR as long as you're not in a position to profit from it and you're not in the business of using amateur radio to facilitate your business. Again the rules were born out of common sense and written on paper, not rock tablets. The intent of the rules is more not to run your cab company using amateur radios vice commercial radio, not to prevent you personally from calling a cab for a ride home! 73 Barry KA0BBQ [Non-text portions of this message have been removed]
[DSTAR_DIGITAL] Loading all of those memories
AE7Q wrote a nice little utility that takes csv files and makes icf for various Icom D-STAR radios (see http://www.d-starcom.com/). My blog is down right now, due to a new router that I am trying to get to do an inbound NAT for the webserver, but there's a pretty good step-by-step article there. What has been missing is a convenient way to get the frequencies (and for FM, the tones, etc.) into the csv file easily. That has been solved, at least for Western US and most of Canada. Go to http://www.nwham.com/repeaters/ put in your search criteria and when you get a list of repeaters, just select Export-Icom-D-STARcomm and it will generate a CSV file to use with the above utility and your Icom radio programming software. If you register, you can send the site updates on information contained in the database, or add your shiny new D-STAR Stack that Santa brought you. If you visit, send the Admin a nice note and thank him for his efforts. I provided the guidance and he did all of the work! :) -- John D. Hays Amateur Radio Station K7VE http://k7ve.ampr.org PO Box 1223 Edmonds, WA 98020-1223 mailto:j...@hays.org [Non-text portions of this message have been removed]
