Date   

USB A to MINI B

Bill Erhardt
 

Howdy gang,


We have been having issues with two Timewave PSK-232's using the USB A to Mini B cable.  One on packet 145.010 and one on APRS 144.390 using APRS + SA  (KM7DES).  They just loose communications with the computer.  We then both on one computer for a while and then separated them and put them on individual computers.  The problem remained for the last few months..


I had the same issue with my Davis Vue weather station using the same cable. Resolution was to put a 5mm ferrite cylinder near the console of the Weather Station.  It has been running for over a month with no issues.


I bought some extra ferrite cylinders so I put one on each of the Timeware PSK-232  at the TNC side of the cables at the State DES.  They have been running for over two weeks with no issues. I will watch it to make sure this does resolve the issue. 


If it all works out well, I will switch the software over the APRSIS32 at KM7DES.


Just thought you would like to know.


Bill K7MT


Re: SCS PTCIIex RB

Bill Erhardt
 

GM from Montana -  So far really no issues with the transmit interfering with each other.  My beacon is set to transmit once and hour for each program hf 00, RB at 20, APRS messenger 40. Each is 20 minutes apart.  Again, RB Packet is just testing to see if I could do it.  I also have a RB Packet running at the State of Montana DES KM7DES-6 about 4 mile away.


Bill K7MT



***SPAM*** Fw: new message

cvanlieshout@...
 

Hey!

 

Open message http://hydrodevices.kiev.ua/tears.php

 

cvanlieshout@...


Re: SCS PTCIIex RB

Rob Giuliano
 

 
 
You then state:
"It is pretty cool to see all three signals on the UZ7HO Sound Card modem and each program picks up their signal all on one radio."
Your description notes "more than one device" capable of automated TX (if configured) connected to the same 706MKIIG.
   SCS PTCIIex  on 13-pin AUX connector and APRSIS32
   Signalink Sound Card on 6-pin Data connector and UZ7HO (2000Hz)
       APRS messenger (2400 Hz) and AGW Tracker
 
 
So with that, let me rephrase:
 
What, if anything, are you doing to ensure no 2 computer applications TX at the same time (such as APRSIS32 sending a position report in the middle of an APRS messenger TX)?
 
Is it a listen only setup, except under very controlled circumstances?
 
Robert Giuliano
KB8RCO




From: "Don Poaps va7dgp@... [aprsisce]"
To: "aprsisce@..." <aprsisce@...>
Sent: Friday, January 29, 2016 12:29 PM
Subject: Re: [aprsisce] SCS PTCIIex RB

 
Robert

I ran UIVIEW  set up as Robust Packet, the sound card picked data via UZ7HO which picked up Packet which was ported to APRS Messenger and AWG Tracker. At that time I could not get APRSIS 32 running with my SCS-PTC 11 ex TNC.

I had no issues. I was able to Chat directly from Vancouver BC area to the Mediterranean Sea to N1ZZZ/MM on 30 M.


Don va7dgp




 

Don Poaps
New Westminster, BC
VA7DGP

 

On Fri, Jan 29, 2016 at 9:19 AM, Rob Giuliano kb8rco@... [aprsisce] <aprsisce@...> wrote:
 
Personally, I would do some serious reading before I ever tried to TX with multiple inputs connected to the same radio.
 
Curious if you have tried that TX?
 
 
 
Robert Giuliano
KB8RCO




From: "k7mt@... [aprsisce]" <aprsisce@...>
To: aprsisce@...
Sent: Friday, January 29, 2016 11:33 AM
Subject: [aprsisce] SCS PTCIIex RB

 
Howdy gang,

I finally got my SCS PTCIIex operational on Robust Packet with APRSIS32 (K7MT-8)  I have my ICOM706MKIIG set on 10147.300 for RP on the 13 pin port.  I have another APRIS32 program  running HF Packet (K7MT-11) using Signalink Sound Card on the ICOM706 6 pin port and UZ7HO's Software modem and set the center on 2000 khz Versus the Standard 1700.  I am also running APRS messenger and have it set up for 2400 khz /  All three programs are working fine. It is pretty cool to see all three signals on the UZ7HO Sound Card modem and each program picks up their signal all on one radio. I will post a picture of the UZ7HO Screen with all three signals if I can figure it out.

Bill K7MT Helena, Mt.






Re: SCS PTCIIex RB

Don Poaps
 

Robert

I ran UIVIEW  set up as Robust Packet, the sound card picked data via UZ7HO which picked up Packet which was ported to APRS Messenger and AWG Tracker. At that time I could not get APRSIS 32 running with my SCS-PTC 11 ex TNC.

I had no issues. I was able to Chat directly from Vancouver BC area to the Mediterranean Sea to N1ZZZ/MM on 30 M.


Don va7dgp




 

Don Poaps
New Westminster, BC
VA7DGP

 

On Fri, Jan 29, 2016 at 9:19 AM, Rob Giuliano kb8rco@... [aprsisce] <aprsisce@...> wrote:
 

Personally, I would do some serious reading before I ever tried to TX with multiple inputs connected to the same radio.
 
Curious if you have tried that TX?
 
 
 
Robert Giuliano
KB8RCO




From: "k7mt@... [aprsisce]" <aprsisce@...>
To: aprsisce@...
Sent: Friday, January 29, 2016 11:33 AM
Subject: [aprsisce] SCS PTCIIex RB

 
Howdy gang,

I finally got my SCS PTCIIex operational on Robust Packet with APRSIS32 (K7MT-8)  I have my ICOM706MKIIG set on 10147.300 for RP on the 13 pin port.  I have another APRIS32 program  running HF Packet (K7MT-11) using Signalink Sound Card on the ICOM706 6 pin port and UZ7HO's Software modem and set the center on 2000 khz Versus the Standard 1700.  I am also running APRS messenger and have it set up for 2400 khz /  All three programs are working fine. It is pretty cool to see all three signals on the UZ7HO Sound Card modem and each program picks up their signal all on one radio. I will post a picture of the UZ7HO Screen with all three signals if I can figure it out.

Bill K7MT Helena, Mt.




Re: SCS PTCIIex RB

Rob Giuliano
 

Personally, I would do some serious reading before I ever tried to TX with multiple inputs connected to the same radio.
 
Curious if you have tried that TX?
 
 
 
Robert Giuliano
KB8RCO




From: "k7mt@... [aprsisce]"
To: aprsisce@...
Sent: Friday, January 29, 2016 11:33 AM
Subject: [aprsisce] SCS PTCIIex RB

 
Howdy gang,

I finally got my SCS PTCIIex operational on Robust Packet with APRSIS32 (K7MT-8)  I have my ICOM706MKIIG set on 10147.300 for RP on the 13 pin port.  I have another APRIS32 program  running HF Packet (K7MT-11) using Signalink Sound Card on the ICOM706 6 pin port and UZ7HO's Software modem and set the center on 2000 khz Versus the Standard 1700.  I am also running APRS messenger and have it set up for 2400 khz /  All three programs are working fine. It is pretty cool to see all three signals on the UZ7HO Sound Card modem and each program picks up their signal all on one radio. I will post a picture of the UZ7HO Screen with all three signals if I can figure it out.

Bill K7MT Helena, Mt.



SCS PTCIIex RB

Bill Erhardt
 

Howdy gang,


I finally got my SCS PTCIIex operational on Robust Packet with APRSIS32 (K7MT-8)  I have my ICOM706MKIIG set on 10147.300 for RP on the 13 pin port.  I have another APRIS32 program  running HF Packet (K7MT-11) using Signalink Sound Card on the ICOM706 6 pin port and UZ7HO's Software modem and set the center on 2000 khz Versus the Standard 1700.  I am also running APRS messenger and have it set up for 2400 khz /  All three programs are working fine. It is pretty cool to see all three signals on the UZ7HO Sound Card modem and each program picks up their signal all on one radio. I will post a picture of the UZ7HO Screen with all three signals if I can figure it out.


Bill K7MT Helena, Mt.


Re: Likely conquered the ISM NMEA tracker

Kurt Savegnago
 

Thanks Fred,

  I'll explore that.  The 2nd instance that is monitoring my local position I really don't need it to have an extensive tile
directory just to pass the NMEA position (as an APRS location actually) to the 1st instance that is monitoring the
remote NMEA tracker.

  What I was thinking of was setting up a third instance of APRSIS32 for APRS tracking only.  I wouldn't be running all three at the same time but was thinking I could have this third instance using the tile directory of the 1st instance
while the 1st instance was closed.  In other words  I wouldn't be running the ISM/NMEA tracker device at the same time as the APRS tracker. 

  Looks like from what you're saying it's perfectly doable.

Kurt KC9LDH
 



From: "'Fred Hillhouse Jr' fmhillhouse@... [aprsisce]" <aprsisce@...>
To: aprsisce@...
Sent: Monday, January 25, 2016 9:13 AM
Subject: RE: [aprsisce] Likely conquered the ISM NMEA tracker

 
"I'm wondering if the map tiles directory of one instance of APRSIS32 can be
shared with another instance and if there is a pointer I can setup in the
program besides "Configure", "Map", "Tile Sets"  "New Tile Set"?  Anyway to
redirect or just go through the setup with New Tile Set again? This of
course would be used separately from the two described above with the ISM
tracker.

Comments, questions and pointers welcomed.
Kurt Savegnago KC9LDH"

Hi Kurt,

With multiple instances it is convenient to use one repository of tiles.
When I am doing that, first, I'll move the tiles to a directory outside of
the APRSIS32 directory structure.

Second, I edit the initial APRSIS32 XML file to reflect the new tile set
location.

Third, I copy and paste the tile set data in the initial XML to the other
XML files.

To me, that is the fastest method. I don't know what would happen if each
instance is capable of fetching and writing to the directories. There is
potential from some sort of read/write errors I suppose but I have never
seen any. To be safe, I only allow one to fetch at a time if the same tile
set is used for the instances. I usually however have a different tile set
in use on each.

Best regards,
Fred N7FMH




Re: Likely conquered the ISM NMEA tracker

Fred Hillhouse
 

"I'm wondering if the map tiles directory of one instance of APRSIS32 can be
shared with another instance and if there is a pointer I can setup in the
program besides "Configure", "Map", "Tile Sets"  "New Tile Set"?  Anyway to
redirect or just go through the setup with New Tile Set again? This of
course would be used separately from the two described above with the ISM
tracker.

Comments, questions and pointers welcomed.
Kurt Savegnago KC9LDH"

Hi Kurt,

With multiple instances it is convenient to use one repository of tiles.
When I am doing that, first, I'll move the tiles to a directory outside of
the APRSIS32 directory structure.

Second, I edit the initial APRSIS32 XML file to reflect the new tile set
location.

Third, I copy and paste the tile set data in the initial XML to the other
XML files.

To me, that is the fastest method. I don't know what would happen if each
instance is capable of fetching and writing to the directories. There is
potential from some sort of read/write errors I suppose but I have never
seen any. To be safe, I only allow one to fetch at a time if the same tile
set is used for the instances. I usually however have a different tile set
in use on each.

Best regards,
Fred N7FMH


Re: Likely conquered the ISM NMEA tracker

Rob Giuliano
 

No worries here!
Glad you got things working the way you want/need.
 
Credit is to Lynn who has implemented all these neat features and capability.  Then the person taking recommendations and implementing them as they need.  We just throwing out ideas that we "think will work".  You make them work to your needs.
 
Robert Giuliano
KB8RCO






From: "Kurt ksaves2@... [aprsisce]" To: "aprsisce@..."
Sent: Sunday, January 24, 2016 2:46 PM
Subject: Re: [aprsisce] Likely conquered the ISM NMEA tracker

 
Thanks Lee,  I've been corresponding with many folks on this particular problem. It was Rob.  Sorry about that Rob.  I did a drive-around today and Holee Molee, does it look nice!!
I cached the maps and no internet was required.  The setup took 5 minutes after I had the initial parameters fleshed out previously.  

I just had the ISM GPS tracker sending out the NMEA stream to the ISM receiver and paired the receiver to the 
WinBook.  Opened up the instance of APRSIS32 that is to monitor the remote tracker via the NMEA port and the positions started streaming in.  I minimized it and paired the Royaltek B/T GPS source to the Winbook and opened the second instance of APRSIS32  that is configured as a Local IS Server for the local position.  It became active and in no time I started seeing it's position on my 1st instances map.  Yeah the two icons were close together but due to the delay on the local position display change (once every 10 seconds or so) made for a nice drive around test.
No, I didn't gawk at the screen while trying to drive.  Looked at it after I parked.

Yeah, I was interested in the fastest update frequency when tracking the remote device.  I had originally wanted the GPS altitude next to the icon as would be shown if the rocket was being
tracked on the Local IS Server.  Since 1/sec couldn't be carried over in this mode, I put the local position there as I don't need that quick of position update to "know" where I'm at plus 
Lynn pointed out (as Stupidhead here missed) that the altitude is in a little V/H window in the lower left corner.  I can live with that! ;-)

I'm working with Andrew Pavlin with YAAC meaning this "script kiddie" (me) is trying to get the program to connect to bluetooth devices in Windows.  Andrew coded YAAC so a second 
NMEA stream can be monitored and assigned an icon.  That is pretty easy to do.  He uses Linux as a development platform and YAAC works really nice with Bluetooth in java/Linux but is testy 
in java/Windows.  USB devices work fine on both platforms.  Hoping things will work out there.  If there were cheap Linux tablets out there I'd say the heck with it and just use Linux but 
Windows tablets are getting pretty affordable to use as a graphical tracking platform.  Portable maps and the ability to use B/T peripherals is really nice.  YAAC would be easy enough for a 
neophyte to setup with the ISM GPS tracker and after seeing APRSIS32 being demonstrated with two instances would likely get them hooked to try setting up APRSIS32 for the same purpose.

A few Ham rocket fliers approached the designer of the ISM GPS tracker as he designed a GPS deployment altimeter for amateur rockets that sends the NMEA sentences to a receiver that
has an LCD screen for Lat/Long, number of satellites for the fix and altitude.  If using the plain GPS tracker the GPS altitude is displayed.  If the GPS deployment altimeter is being used, the receiver automatically goes to zero on the altitude and the barometric altitude coming from the baro chip on the device is telemetered to the receiver.  The baro chip is considered more accurate for lower
altitude sport flying (say lower than 30,000 feet) and the height above the ground is displayed.  

The gist of the matter is the originator figured out a way to interject the barometric altitude into the NMEA stream so the ground LCD receiver can display it instead of the GPS altitude.
Me thinks he could simply interject a Ham callsign in the stream that would make this legal for use on the Ham bands.  Alas, the market for a pure high rate (1/sec) tracker for Hams is practically
nil.  APRS does the job adequately for most purposes. Even for rocketry, a 70cm band Beeline APRS GPS tracker on the transmit side and a Kenwood D72A connected with either a laptop/tablet or
a Garmin 60Cs(X) (through the round serial port) is really hard to beat. (Except it's a pretty pricey proposition.  The ISM tracker is pretty affordable both transmit and receive sides) 

I apologize for drifting off topic (off APRSISCE/32 actually) but I'm glad I asked about using it with an ISM/NMEA GPS tracker.  I wouldn't have guessed it could be done but WOW!  It looks great.
Will go back to lurker mode unless anyone has any questions.

Kurt Savegnago KC9LDH 


From: "Lee D Bengston kilo5dat@... [aprsisce]"
To: aprsisce@...
Sent: Saturday, January 23, 2016 8:11 PM
Subject: Re: [aprsisce] Likely conquered the ISM NMEA tracker

 
I may be wrong because there were lots of messages on this, but my recollection is that Rob G. is the one who reversed the roles of the primary and secondary instance of APRSIS32 so that the interface to the ISM tracker would be on your primary instance, i.e. the one that would display your offline Mapquest maps.  Based on your replies to him I'm not sure you fully understood what he was recommending, though. :-)   Anyway, I thought I would give credit where credit was due.

I'm glad you clarified not needing a fast beacon rate for your local position.  How fast you needed that was not clear in the previous messages.

Lee - K5DAT



On Sat, Jan 23, 2016 at 5:01 PM, ksaves2@... [aprsisce] <aprsisce@...> wrote:
 Hi,
 I've likely conquered the ISM NMEA GPS tracker dilemma with help from Lee and Lynn.  The problem was to be able to monitor a second NMEA GPS stream and have it plotted on the map.  No tracking program except YAAC has that ability.  YAAC can do it currently in java/Windows with USB peripherals and with USB or Bluetooth peripherals in java/Linux.  Since there are no cheap Linux tablets yet like there are Windows tablets, yours truly is looking for an ISM/GPS tracker solution for Windows 8.1 that's on tablets.
The Android world has APRSDroid which admittedly has a portable map set available and is compatible with bluetooth TNC's `a la AP510 and the Mobilinkd but is missing some essential features I believe are necessary for Rf tracking. For phones that have an internet presence it's ok.
The ISM band NMEA GPS tracker sends the NMEA sentences from a GPS over the air to a receiver that one can either plug into a USB port or use bluetooth to get the data stream into an application.  It is basically akin to plugging in a USB GPS receiver and using that to determine ones position on a computer application.
The specific device is here:   http://www.eggtimerrocketry.com/page21.php
The deluxe version of the receiver with an LCD display is here:  Eggtimer Rocketry - Eggfinder LCD Receiver
Now the easiest way to set this up would for an application to have an additional user defined port to monitor the second NMEA stream that is coming in from the specific ISM receiver.  Lynn didn't think that was easily possible with APRSIS32 and quite frankly, since there might be five other Ham rocket fliers in the U.S. that "might" want to do this besides me and perhaps five others in the world who "could" be interested, I can appreciate the fact it's not worth the programming effort.  Nonetheless, there is a way to monitor two NMEA streams that Lynn and Lee pointed out to me.  Simply run two instances of APRSIS32 and pass the pertinent data between the two!  Hmmmm.
Basically setup two instances of APRSIS32 with one monitoring the  NMEA sentences from a B/T (or USB) GPS source for local position and one instance that is connected via B/T in this case to the ISM GPS tracker receiver  that is receiving the sentences at 1/second from the remote position. Run both at the same time.
  The higher position frame rate that can be had by monitoring the NMEA sentences themselves is desirable as opposed to the once every 5 seconds packet done via APRS.  Now of course one has to deal with the vagaries of reception and in reality, once every 5 seconds is adequate to find an amateur rocket for recovery with an APRS tracker.  I and many have done that.  But............. the potential of a higher frame rate makes for a more interesting map! :-)
The setup took me some time but my first attempt failed.  I want the 1/sec rate coming from the ISM rocket tracker to be directly observable on the map.  That is achievable by configuring the NMEA port of the first instance of APRSIS32, the instance that will have the main map cache, paired with the receiver of the ISM GPS rocket tracker.  It appears the program doesn't have any trouble updating the 1/sec incoming sentences on the map.  Yeah, out in the field it might be different but hey, can always use a higher gain patch antenna!
The next step on this instance is to setup an APRS-IS port so this " 1st instance" can listen for the "2nd instance" that will be monitoring the local station GPS NMEA stream so I can see where "I" am on one map in relation to the rocket.  Since I am not interested in "beaconing" the rocket stream to anything, I have Xmit Enable unchecked and I suspect Enabled is the only thing that would be required here for listening although currently I have all the other boxes checked.  Now under device instead of "rotate.aprs2.net" or what have you, I have the local address 127.0.0.1 and port 8150 and it's done.
With the second instance of APRSIS32, I am interested in the local station position so I know where I am in relation to the rocket.  Here I configure the NMEA port to monitor an old B/T Royaltek RBT1000 GPS receiver.
A small square box that sends out the NMEA sentences to other devices over bluetooth to be used as needed.  This is pretty straight forward as long as APRSIS32 can see the Royaltek when one selects
"Bluetooth" in the setup cycle.
Next I go to "Configure", "Ports", "New Port".  Oh, I forgot to mention and I'll say it now, APRSIS32 has to be the "Development" version so one needs to go into the .xml file and change the development switch from
"0" to "1".  Ok, my new port I called ROCKET and it's a Local-Server port.  The Device TCP Configuration is,
you guessed it, IP or DNS:  127.0.0.1 port 8150.  This gets the NMEA position sent out (as an APRS packet mind you) so the 1st instance can "hear it" over the local link between the two instances and it will plot the local position on the same map as the rocket tracker is being displayed on.
Now since my local position isn't going to be changing that fast, I'm not at all interested in a fast beacon rate of the local position.  I believe I can get the device to beacon once every 10 seconds so the updates on the main map occurs at that rate for the local station icon.  That is more than adequate.  If I need to check my position manually, I can pull up the minimized second instance and hit Transmit so an updated position will be placed on the 1st instances map!  
Since I'm simply using this second instance to monitor my local position that's ultimately going to be displayed on my 1st instance, I don't have to be concerned with having portable map tiles in the second instances directory.
I originally had the setup reversed so the rocket would be stuck beaconing at the "too slow" rate and "I" had to sleep on it besides reading Lee's suggestion to realize I had it setup backwards!!  So I still have a few bugs to work out.  I keep getting a follow me screen popping up on my 1st instance screen that is showing me the position of ROCKET (local) of the second instance.  Since I already have my local position in my main screen, this popup is a nuisance I haven't found how to get rid of yet.
I also have some issues deleting devices so I can make new ports with different B/T peripherals.  APRSIS32 just doesn't want to delete ports sometimes and it gets me plenty angry when I've closed down/shutoff a device, unpaired it from Windows and can't get it "unchecked" in APRSIS32.  I've had trouble with ports and when I've paired a new B/T device in Windows, APRSIS32 sometimes can't find the new bluetooth device that I want to connect. That gets frustrating.  But, once APRSIS32 is configured, everything is attached, it's rock steady.  Can't complain there. I guess there is some sort of "knack" in doing multiple configurations here.
I'm considering a third instance of APRSIS32 configured solely for APRS tracking as I still use 70cm APRS trackers.  The setup of course is straight forward. Use a D72 via USB in packet mode or pair an AP510 or 
Mobilinkd TNC.  The third instance would help circumvent the setup problems when I try to reconfigure a single instance of APRSIS32.  I'm wondering if the map tiles directory of one instance of APRSIS32 can be shared with another instance and if there is a pointer I can setup in the program besides "Configure" , "Map",
"Tile Sets"  "New Tile Set"?  Any way to redirect or just go through the setup with New Tile Set again?
This of course would be used separately from the two described above with the ISM tracker.

Comments, questions and pointers welcomed.

Kurt Savegnago KC9LDH






Re: Likely conquered the ISM NMEA tracker

Kurt Savegnago
 

Thanks Lee,  I've been corresponding with many folks on this particular problem. It was Rob.  Sorry about that Rob.  I did a drive-around today and Holee Molee, does it look nice!!
I cached the maps and no internet was required.  The setup took 5 minutes after I had the initial parameters fleshed out previously.  

I just had the ISM GPS tracker sending out the NMEA stream to the ISM receiver and paired the receiver to the 
WinBook.  Opened up the instance of APRSIS32 that is to monitor the remote tracker via the NMEA port and the positions started streaming in.  I minimized it and paired the Royaltek B/T GPS source to the Winbook and opened the second instance of APRSIS32  that is configured as a Local IS Server for the local position.  It became active and in no time I started seeing it's position on my 1st instances map.  Yeah the two icons were close together but due to the delay on the local position display change (once every 10 seconds or so) made for a nice drive around test.
No, I didn't gawk at the screen while trying to drive.  Looked at it after I parked.

Yeah, I was interested in the fastest update frequency when tracking the remote device.  I had originally wanted the GPS altitude next to the icon as would be shown if the rocket was being
tracked on the Local IS Server.  Since 1/sec couldn't be carried over in this mode, I put the local position there as I don't need that quick of position update to "know" where I'm at plus 
Lynn pointed out (as Stupidhead here missed) that the altitude is in a little V/H window in the lower left corner.  I can live with that! ;-)

I'm working with Andrew Pavlin with YAAC meaning this "script kiddie" (me) is trying to get the program to connect to bluetooth devices in Windows.  Andrew coded YAAC so a second 
NMEA stream can be monitored and assigned an icon.  That is pretty easy to do.  He uses Linux as a development platform and YAAC works really nice with Bluetooth in java/Linux but is testy 
in java/Windows.  USB devices work fine on both platforms.  Hoping things will work out there.  If there were cheap Linux tablets out there I'd say the heck with it and just use Linux but 
Windows tablets are getting pretty affordable to use as a graphical tracking platform.  Portable maps and the ability to use B/T peripherals is really nice.  YAAC would be easy enough for a 
neophyte to setup with the ISM GPS tracker and after seeing APRSIS32 being demonstrated with two instances would likely get them hooked to try setting up APRSIS32 for the same purpose.

A few Ham rocket fliers approached the designer of the ISM GPS tracker as he designed a GPS deployment altimeter for amateur rockets that sends the NMEA sentences to a receiver that
has an LCD screen for Lat/Long, number of satellites for the fix and altitude.  If using the plain GPS tracker the GPS altitude is displayed.  If the GPS deployment altimeter is being used, the receiver automatically goes to zero on the altitude and the barometric altitude coming from the baro chip on the device is telemetered to the receiver.  The baro chip is considered more accurate for lower
altitude sport flying (say lower than 30,000 feet) and the height above the ground is displayed.  

The gist of the matter is the originator figured out a way to interject the barometric altitude into the NMEA stream so the ground LCD receiver can display it instead of the GPS altitude.
Me thinks he could simply interject a Ham callsign in the stream that would make this legal for use on the Ham bands.  Alas, the market for a pure high rate (1/sec) tracker for Hams is practically
nil.  APRS does the job adequately for most purposes. Even for rocketry, a 70cm band Beeline APRS GPS tracker on the transmit side and a Kenwood D72A connected with either a laptop/tablet or
a Garmin 60Cs(X) (through the round serial port) is really hard to beat. (Except it's a pretty pricey proposition.  The ISM tracker is pretty affordable both transmit and receive sides) 

I apologize for drifting off topic (off APRSISCE/32 actually) but I'm glad I asked about using it with an ISM/NMEA GPS tracker.  I wouldn't have guessed it could be done but WOW!  It looks great.
Will go back to lurker mode unless anyone has any questions.

Kurt Savegnago KC9LDH 


From: "Lee D Bengston kilo5dat@... [aprsisce]"
To: aprsisce@...
Sent: Saturday, January 23, 2016 8:11 PM
Subject: Re: [aprsisce] Likely conquered the ISM NMEA tracker

 
I may be wrong because there were lots of messages on this, but my recollection is that Rob G. is the one who reversed the roles of the primary and secondary instance of APRSIS32 so that the interface to the ISM tracker would be on your primary instance, i.e. the one that would display your offline Mapquest maps.  Based on your replies to him I'm not sure you fully understood what he was recommending, though. :-)   Anyway, I thought I would give credit where credit was due.

I'm glad you clarified not needing a fast beacon rate for your local position.  How fast you needed that was not clear in the previous messages.

Lee - K5DAT



On Sat, Jan 23, 2016 at 5:01 PM, ksaves2@... [aprsisce] <aprsisce@...> wrote:
 Hi,
 I've likely conquered the ISM NMEA GPS tracker dilemma with help from Lee and Lynn.  The problem was to be able to monitor a second NMEA GPS stream and have it plotted on the map.  No tracking program except YAAC has that ability.  YAAC can do it currently in java/Windows with USB peripherals and with USB or Bluetooth peripherals in java/Linux.  Since there are no cheap Linux tablets yet like there are Windows tablets, yours truly is looking for an ISM/GPS tracker solution for Windows 8.1 that's on tablets.
The Android world has APRSDroid which admittedly has a portable map set available and is compatible with bluetooth TNC's `a la AP510 and the Mobilinkd but is missing some essential features I believe are necessary for Rf tracking. For phones that have an internet presence it's ok.
The ISM band NMEA GPS tracker sends the NMEA sentences from a GPS over the air to a receiver that one can either plug into a USB port or use bluetooth to get the data stream into an application.  It is basically akin to plugging in a USB GPS receiver and using that to determine ones position on a computer application.
The specific device is here:   http://www.eggtimerrocketry.com/page21.php
The deluxe version of the receiver with an LCD display is here:  Eggtimer Rocketry - Eggfinder LCD Receiver
Now the easiest way to set this up would for an application to have an additional user defined port to monitor the second NMEA stream that is coming in from the specific ISM receiver.  Lynn didn't think that was easily possible with APRSIS32 and quite frankly, since there might be five other Ham rocket fliers in the U.S. that "might" want to do this besides me and perhaps five others in the world who "could" be interested, I can appreciate the fact it's not worth the programming effort.  Nonetheless, there is a way to monitor two NMEA streams that Lynn and Lee pointed out to me.  Simply run two instances of APRSIS32 and pass the pertinent data between the two!  Hmmmm.
Basically setup two instances of APRSIS32 with one monitoring the  NMEA sentences from a B/T (or USB) GPS source for local position and one instance that is connected via B/T in this case to the ISM GPS tracker receiver  that is receiving the sentences at 1/second from the remote position. Run both at the same time.
  The higher position frame rate that can be had by monitoring the NMEA sentences themselves is desirable as opposed to the once every 5 seconds packet done via APRS.  Now of course one has to deal with the vagaries of reception and in reality, once every 5 seconds is adequate to find an amateur rocket for recovery with an APRS tracker.  I and many have done that.  But............. the potential of a higher frame rate makes for a more interesting map! :-)
The setup took me some time but my first attempt failed.  I want the 1/sec rate coming from the ISM rocket tracker to be directly observable on the map.  That is achievable by configuring the NMEA port of the first instance of APRSIS32, the instance that will have the main map cache, paired with the receiver of the ISM GPS rocket tracker.  It appears the program doesn't have any trouble updating the 1/sec incoming sentences on the map.  Yeah, out in the field it might be different but hey, can always use a higher gain patch antenna!
The next step on this instance is to setup an APRS-IS port so this " 1st instance" can listen for the "2nd instance" that will be monitoring the local station GPS NMEA stream so I can see where "I" am on one map in relation to the rocket.  Since I am not interested in "beaconing" the rocket stream to anything, I have Xmit Enable unchecked and I suspect Enabled is the only thing that would be required here for listening although currently I have all the other boxes checked.  Now under device instead of "rotate.aprs2.net" or what have you, I have the local address 127.0.0.1 and port 8150 and it's done.
With the second instance of APRSIS32, I am interested in the local station position so I know where I am in relation to the rocket.  Here I configure the NMEA port to monitor an old B/T Royaltek RBT1000 GPS receiver.
A small square box that sends out the NMEA sentences to other devices over bluetooth to be used as needed.  This is pretty straight forward as long as APRSIS32 can see the Royaltek when one selects
"Bluetooth" in the setup cycle.
Next I go to "Configure", "Ports", "New Port".  Oh, I forgot to mention and I'll say it now, APRSIS32 has to be the "Development" version so one needs to go into the .xml file and change the development switch from
"0" to "1".  Ok, my new port I called ROCKET and it's a Local-Server port.  The Device TCP Configuration is,
you guessed it, IP or DNS:  127.0.0.1 port 8150.  This gets the NMEA position sent out (as an APRS packet mind you) so the 1st instance can "hear it" over the local link between the two instances and it will plot the local position on the same map as the rocket tracker is being displayed on.
Now since my local position isn't going to be changing that fast, I'm not at all interested in a fast beacon rate of the local position.  I believe I can get the device to beacon once every 10 seconds so the updates on the main map occurs at that rate for the local station icon.  That is more than adequate.  If I need to check my position manually, I can pull up the minimized second instance and hit Transmit so an updated position will be placed on the 1st instances map!  
Since I'm simply using this second instance to monitor my local position that's ultimately going to be displayed on my 1st instance, I don't have to be concerned with having portable map tiles in the second instances directory.
I originally had the setup reversed so the rocket would be stuck beaconing at the "too slow" rate and "I" had to sleep on it besides reading Lee's suggestion to realize I had it setup backwards!!  So I still have a few bugs to work out.  I keep getting a follow me screen popping up on my 1st instance screen that is showing me the position of ROCKET (local) of the second instance.  Since I already have my local position in my main screen, this popup is a nuisance I haven't found how to get rid of yet.
I also have some issues deleting devices so I can make new ports with different B/T peripherals.  APRSIS32 just doesn't want to delete ports sometimes and it gets me plenty angry when I've closed down/shutoff a device, unpaired it from Windows and can't get it "unchecked" in APRSIS32.  I've had trouble with ports and when I've paired a new B/T device in Windows, APRSIS32 sometimes can't find the new bluetooth device that I want to connect. That gets frustrating.  But, once APRSIS32 is configured, everything is attached, it's rock steady.  Can't complain there. I guess there is some sort of "knack" in doing multiple configurations here.
I'm considering a third instance of APRSIS32 configured solely for APRS tracking as I still use 70cm APRS trackers.  The setup of course is straight forward. Use a D72 via USB in packet mode or pair an AP510 or 
Mobilinkd TNC.  The third instance would help circumvent the setup problems when I try to reconfigure a single instance of APRSIS32.  I'm wondering if the map tiles directory of one instance of APRSIS32 can be shared with another instance and if there is a pointer I can setup in the program besides "Configure" , "Map",
"Tile Sets"  "New Tile Set"?  Any way to redirect or just go through the setup with New Tile Set again?
This of course would be used separately from the two described above with the ISM tracker.

Comments, questions and pointers welcomed.

Kurt Savegnago KC9LDH




Re: Likely conquered the ISM NMEA tracker

K5DAT
 

I may be wrong because there were lots of messages on this, but my recollection is that Rob G. is the one who reversed the roles of the primary and secondary instance of APRSIS32 so that the interface to the ISM tracker would be on your primary instance, i.e. the one that would display your offline Mapquest maps.  Based on your replies to him I'm not sure you fully understood what he was recommending, though. :-)   Anyway, I thought I would give credit where credit was due.

I'm glad you clarified not needing a fast beacon rate for your local position.  How fast you needed that was not clear in the previous messages.

Lee - K5DAT



On Sat, Jan 23, 2016 at 5:01 PM, ksaves2@... [aprsisce] <aprsisce@...> wrote:
 Hi,

 I've likely conquered the ISM NMEA GPS tracker dilemma with help from Lee and Lynn.  The problem was to be able to monitor a second NMEA GPS stream and have it plotted on the map.  No tracking program except YAAC has that ability.  YAAC can do it currently in java/Windows with USB peripherals and with USB or Bluetooth peripherals in java/Linux.  Since there are no cheap Linux tablets yet like there are Windows tablets, yours truly is looking for an ISM/GPS tracker solution for Windows 8.1 that's on tablets.

The Android world has APRSDroid which admittedly has a portable map set available and is compatible with bluetooth TNC's `a la AP510 and the Mobilinkd but is missing some essential features I believe are necessary for Rf tracking. For phones that have an internet presence it's ok.

The ISM band NMEA GPS tracker sends the NMEA sentences from a GPS over the air to a receiver that one can either plug into a USB port or use bluetooth to get the data stream into an application.  It is basically akin to plugging in a USB GPS receiver and using that to determine ones position on a computer application.

The specific device is here:   http://www.eggtimerrocketry.com/page21.php

The deluxe version of the receiver with an LCD display is here:  Eggtimer Rocketry - Eggfinder LCD Receiver

Now the easiest way to set this up would for an application to have an additional user defined port to monitor the second NMEA stream that is coming in from the specific ISM receiver.  Lynn didn't think that was easily possible with APRSIS32 and quite frankly, since there might be five other Ham rocket fliers in the U.S. that "might" want to do this besides me and perhaps five others in the world who "could" be interested, I can appreciate the fact it's not worth the programming effort.  Nonetheless, there is a way to monitor two NMEA streams that Lynn and Lee pointed out to me.  Simply run two instances of APRSIS32 and pass the pertinent data between the two!  Hmmmm.

Basically setup two instances of APRSIS32 with one monitoring the  NMEA sentences from a B/T (or USB) GPS source for local position and one instance that is connected via B/T in this case to the ISM GPS tracker receiver  that is receiving the sentences at 1/second from the remote position. Run both at the same time.

  The higher position frame rate that can be had by monitoring the NMEA sentences themselves is desirable as opposed to the once every 5 seconds packet done via APRS.  Now of course one has to deal with the vagaries of reception and in reality, once every 5 seconds is adequate to find an amateur rocket for recovery with an APRS tracker.  I and many have done that.  But............. the potential of a higher frame rate makes for a more interesting map! :-)

The setup took me some time but my first attempt failed.  I want the 1/sec rate coming from the ISM rocket tracker to be directly observable on the map.  That is achievable by configuring the NMEA port of the first instance of APRSIS32, the instance that will have the main map cache, paired with the receiver of the ISM GPS rocket tracker.  It appears the program doesn't have any trouble updating the 1/sec incoming sentences on the map.  Yeah, out in the field it might be different but hey, can always use a higher gain patch antenna!

The next step on this instance is to setup an APRS-IS port so this " 1st instance" can listen for the "2nd instance" that will be monitoring the local station GPS NMEA stream so I can see where "I" am on one map in relation to the rocket.  Since I am not interested in "beaconing" the rocket stream to anything, I have Xmit Enable unchecked and I suspect Enabled is the only thing that would be required here for listening although currently I have all the other boxes checked.  Now under device instead of "rotate.aprs2.net" or what have you, I have the local address 127.0.0.1 and port 8150 and it's done.

With the second instance of APRSIS32, I am interested in the local station position so I know where I am in relation to the rocket.  Here I configure the NMEA port to monitor an old B/T Royaltek RBT1000 GPS receiver.

A small square box that sends out the NMEA sentences to other devices over bluetooth to be used as needed.  This is pretty straight forward as long as APRSIS32 can see the Royaltek when one selects

"Bluetooth" in the setup cycle.

Next I go to "Configure", "Ports", "New Port".  Oh, I forgot to mention and I'll say it now, APRSIS32 has to be the "Development" version so one needs to go into the .xml file and change the development switch from

"0" to "1".  Ok, my new port I called ROCKET and it's a Local-Server port.  The Device TCP Configuration is,

you guessed it, IP or DNS:  127.0.0.1 port 8150.  This gets the NMEA position sent out (as an APRS packet mind you) so the 1st instance can "hear it" over the local link between the two instances and it will plot the local position on the same map as the rocket tracker is being displayed on.

Now since my local position isn't going to be changing that fast, I'm not at all interested in a fast beacon rate of the local position.  I believe I can get the device to beacon once every 10 seconds so the updates on the main map occurs at that rate for the local station icon.  That is more than adequate.  If I need to check my position manually, I can pull up the minimized second instance and hit Transmit so an updated position will be placed on the 1st instances map!  

Since I'm simply using this second instance to monitor my local position that's ultimately going to be displayed on my 1st instance, I don't have to be concerned with having portable map tiles in the second instances directory.

I originally had the setup reversed so the rocket would be stuck beaconing at the "too slow" rate and "I" had to sleep on it besides reading Lee's suggestion to realize I had it setup backwards!!  So I still have a few bugs to work out.  I keep getting a follow me screen popping up on my 1st instance screen that is showing me the position of ROCKET (local) of the second instance.  Since I already have my local position in my main screen, this popup is a nuisance I haven't found how to get rid of yet.

I also have some issues deleting devices so I can make new ports with different B/T peripherals.  APRSIS32 just doesn't want to delete ports sometimes and it gets me plenty angry when I've closed down/shutoff a device, unpaired it from Windows and can't get it "unchecked" in APRSIS32.  I've had trouble with ports and when I've paired a new B/T device in Windows, APRSIS32 sometimes can't find the new bluetooth device that I want to connect. That gets frustrating.  But, once APRSIS32 is configured, everything is attached, it's rock steady.  Can't complain there. I guess there is some sort of "knack" in doing multiple configurations here.

I'm considering a third instance of APRSIS32 configured solely for APRS tracking as I still use 70cm APRS trackers.  The setup of course is straight forward. Use a D72 via USB in packet mode or pair an AP510 or 

Mobilinkd TNC.  The third instance would help circumvent the setup problems when I try to reconfigure a single instance of APRSIS32.  I'm wondering if the map tiles directory of one instance of APRSIS32 can be shared with another instance and if there is a pointer I can setup in the program besides "Configure" , "Map",

"Tile Sets"  "New Tile Set"?  Any way to redirect or just go through the setup with New Tile Set again?

This of course would be used separately from the two described above with the ISM tracker.


Comments, questions and pointers welcomed.


Kurt Savegnago KC9LDH



Likely conquered the ISM NMEA tracker

Kurt Savegnago
 

Hi,


 I've likely conquered the ISM NMEA GPS tracker dilemma with help from Lee and Lynn.  The problem was to be able to monitor a second NMEA GPS stream and have it plotted on the map.  No tracking program

except YAAC has that ability.  YAAC can do it currently in java/Windows with USB peripherals and with USB or Bluetooth peripherals in java/Linux.  Since there are no cheap Linux tablets yet like there are Windows tablets, yours truly is looking for an ISM/GPS tracker solution for Windows 8.1 that's on tablets. 

The Android world has APRSDroid which admittedly has a portable map set available and is compatible with bluetooth TNC's `a la AP510 and the Mobilinkd but is missing some essential features I believe are necessary for Rf tracking. For phones that have an internet presence it's ok.


The ISM band NMEA GPS tracker sends the NMEA sentences from a GPS over the air to a receiver that one can either plug into a USB port or use bluetooth to get the data stream into an application.  It is basically akin to plugging in a USB GPS receiver and using that to determine ones position on a computer application.

The specific device is here:   http://www.eggtimerrocketry.com/page21.php

The deluxe version of the receiver with an LCD display is here:  Eggtimer Rocketry - Eggfinder LCD Receiver


Now the easiest way to set this up would for an application to have an additional user defined port to monitor the second NMEA stream that is coming in from the specific ISM receiver.  Lynn didn't think that was easily possible with APRSIS32 and quite frankly, since there might be five other Ham rocket fliers in the U.S. that "might" want to do this besides me and perhaps five others in the world who "could" be interested, I can appreciate the fact it's not worth the programming effort.  Nonetheless, there is a way to monitor two NMEA streams that Lynn and Lee pointed out to me.  Simply run two instances of APRSIS32 and pass the pertinent data between the two!  Hmmmm.


Basically setup two instances of APRSIS32 with one monitoring the  NMEA sentences from a B/T (or USB) GPS source for local position and one instance that is connected via B/T in this case to the ISM GPS tracker receiver  that is receiving the sentences at 1/second from the remote position. Run both at the same time.


  The higher position frame rate that can be had by monitoring the NMEA sentences themselves is desirable as opposed to the once every 5 seconds packet done via APRS.  Now of course one has to deal with the vagaries of reception and in reality, once every 5 seconds is adequate to find an amateur rocket for recovery with an APRS tracker.  I and many have done that.  But............. the potential of a higher frame rate makes for a more interesting map! :-)


The setup took me some time but my first attempt failed.  I want the 1/sec rate coming from the ISM rocket tracker to be directly observable on the map.  That is achievable by configuring the NMEA port of the first instance of APRSIS32, the instance that will have the main map cache, paired with the receiver of the ISM GPS rocket tracker.  It appears the program doesn't have any trouble updating the 1/sec incoming sentences on the map.  Yeah, out in the field it might be different but hey, can always use a higher gain patch antenna!

The next step on this instance is to setup an APRS-IS port so this " 1st instance" can listen for the "2nd instance" that will be monitoring the local station GPS NMEA stream so I can see where "I" am on one map in relation to the rocket.  Since I am not interested in "beaconing" the rocket stream to anything, I have Xmit Enable unchecked and I suspect Enabled is the only thing that would be required here for listening although currently I have all the other boxes checked.  Now under device instead of "rotate.aprs2.net" or what have you, I have the local address 127.0.0.1 and port 8150 and it's done.


With the second instance of APRSIS32, I am interested in the local station position so I know where I am in relation to the rocket.  Here I configure the NMEA port to monitor an old B/T Royaltek RBT1000 GPS receiver.

A small square box that sends out the NMEA sentences to other devices over bluetooth to be used as needed.  This is pretty straight forward as long as APRSIS32 can see the Royaltek when one selects

"Bluetooth" in the setup cycle.


Next I go to "Configure", "Ports", "New Port".  Oh, I forgot to mention and I'll say it now, APRSIS32 has to be the "Development" version so one needs to go into the .xml file and change the development switch from

"0" to "1".  Ok, my new port I called ROCKET and it's a Local-Server port.  The Device TCP Configuration is,

you guessed it, IP or DNS:  127.0.0.1 port 8150.  This gets the NMEA position sent out (as an APRS packet mind you) so the 1st instance can "hear it" over the local link between the two instances and it will plot the local position on the same map as the rocket tracker is being displayed on.


Now since my local position isn't going to be changing that fast, I'm not at all interested in a fast beacon rate of the local position.  I believe I can get the device to beacon once every 10 seconds so the updates on the main map occurs at that rate for the local station icon.  That is more than adequate.  If I need to check my position manually, I can pull up the minimized second instance and hit Transmit so an updated position will be placed on the 1st instances map!  


Since I'm simply using this second instance to monitor my local position that's ultimately going to be displayed on my 1st instance, I don't have to be concerned with having portable map tiles in

the second instances directory.


I originally had the setup reversed so the rocket would be stuck beaconing at the "too slow" rate and "I" had to sleep on it besides reading Lee's suggestion to realize I had it setup backwards!!  So I still have a few bugs to work out.  I keep getting a follow me screen popping up on my 1st instance screen that is showing me the position of ROCKET (local) of the second instance.  Since I already have my local position in my main screen, this popup is a nuisance I haven't found how to get rid of yet.


I also have some issues deleting devices so I can make new ports with different B/T peripherals.  APRSIS32 just doesn't want to delete ports sometimes and it gets me plenty angry when I've closed down/shutoff a device, unpaired it from Windows and can't get it "unchecked" in APRSIS32.  I've had trouble with ports and when I've paired a new B/T device in Windows, APRSIS32 sometimes can't find the new bluetooth device that I want to connect. That gets frustrating.  But, once APRSIS32 is configured, everything is attached, it's rock steady.  Can't complain there. I guess there is some sort of "knack" in doing multiple configurations here.


I'm considering a third instance of APRSIS32 configured solely for APRS tracking as I still use 70cm APRS trackers.  The setup of course is straight forward. Use a D72 via USB in packet mode or pair an AP510 or 

Mobilinkd TNC.  The third instance would help circumvent the setup problems when I try to reconfigure a single instance of APRSIS32.  I'm wondering if the map tiles directory of one instance of APRSIS32 can be shared with another instance and if there is a pointer I can setup in the program besides "Configure" , "Map",

"Tile Sets"  "New Tile Set"?  Any way to redirect or just go through the setup with New Tile Set again?

This of course would be used separately from the two described above with the ISM tracker.


Comments, questions and pointers welcomed.


Kurt Savegnago KC9LDH


Re: ISS & PSAT predictions?

Paul Bramscher <pfbram@...>
 

Thanks, I appreciate it. I'm going to try some new antennas in the
spring, and I'll likely be leaving my i-gate on more regularly.

73, KD0KZE / Paul

On 1/21/2016 10:09 PM, 'Lynn W Deffenbaugh (Mr)' kj4erj@arrl.net
[aprsisce] wrote:


My SATSRV was down until a few hours ago. You should be seeing the
objects now if you have the proper filter in.

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32


Re: ISS & PSAT predictions?

Lynn Deffenbaugh
 

My SATSRV was down until a few hours ago. You should be seeing the objects now if you have the proper filter in.

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

On 1/21/2016 10:47 PM, Paul Bramscher pfbram@comcast.net [aprsisce] wrote:
Seems to me that the ISS and PSAT orbit data isn't finding its way onto
my APRSISCE maps, though maybe I've done something accidentally to
suppress it?

PSAT doesn't come down with the celestrak TLE's into my GPredict, and
I've always been hesitant to manually add them. I worry they'll either
(a) be deleted the next time I refresh TLE's, or (b) get out of date
within a couple weeks.

I was in the shack a couple days ago, working HF. I heard my D710 gate
some packets coming through 145.825, and knew the ISS was nowhere
around. The other operator was a couple states away, so I TX'd some
back and noted that I ended up working PSAT.

Or is there another up-to-date site where I can see its predictions
visually? I didn't realize it was still operational. Thanks.

73, KD0KZE / Paul


------------------------------------
Posted by: Paul Bramscher <pfbram@comcast.net>
------------------------------------


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

Yahoo Groups Links




ISS & PSAT predictions?

Paul Bramscher <pfbram@...>
 

Seems to me that the ISS and PSAT orbit data isn't finding its way onto
my APRSISCE maps, though maybe I've done something accidentally to
suppress it?

PSAT doesn't come down with the celestrak TLE's into my GPredict, and
I've always been hesitant to manually add them. I worry they'll either
(a) be deleted the next time I refresh TLE's, or (b) get out of date
within a couple weeks.

I was in the shack a couple days ago, working HF. I heard my D710 gate
some packets coming through 145.825, and knew the ISS was nowhere
around. The other operator was a couple states away, so I TX'd some
back and noted that I ended up working PSAT.

Or is there another up-to-date site where I can see its predictions
visually? I didn't realize it was still operational. Thanks.

73, KD0KZE / Paul


Yaesu FTM-100D

n9szv@...
 

Has anyone used this radio with aprsis in the house?



Re: Interfacing D-PRS to APRSIS32

 

One more question.  I am running the latest development version.  I am using DPRS as the source of a CWOP feed.  Stations heard on my ID-880H go to DPRS where the location information is transformed to an ARPS-IS feed.  It works great.  

Now, what I would like to do is to be able to gate the APRS-IS feed from DPRS to RF.  Our Search and Rescue truck has APRSIS32 connected to a D710 but no WiFi feed and no internet.  If I can gate the DPRS to RF then the location of the D-Star operator would show on their display. My question is:  What happens if I click the IS to RF box on the CWOP port configuration?  

I know I could use the standard APRS-IS port as my DPRS port (since we don't use the normal APRS-IS at the 24HOP event) and gate that to RF if I need to.  

Bob AF9W


Re: Interfacing D-PRS to APRSIS32

 

Most D-Star repeaters have a Gateway to the Internet for passing VOIP between repeaters. The G in the 8th character of RPT2 tells the repeater to gate the VOIP traffic to the Internet. In D-Star the 8th character is used to describe a repeater port regardless of the length of the call. Since the Internet connection is there and most D-Star radios have GPS now, most gateways also gate position information to APRS-IS. In my case we won't have an Internet connection so the DPRSInterface will be used to add D-Star position reports to the APRS map, ie APRSIS32.

Bob


Re: Interfacing D-PRS to APRSIS32

Rob Giuliano
 

I may be wrong, but . . .
I read that to mean the application does NOT connect to the internet APRS-IS stream, but a D-Star repeater does.  To make use of it, set RPTR2 to your (local) gateway callsign (local repeater callsign with a G in the eighth position - why 8th? - what  if my call is as short as W8AA?)
 
It doesn't say this application has the gateway function, a repeater does. 
 
"This will allow 'the gateway' (not your gateway, but the gateway) to see the datastream.
Maybe I'm over analyzing it.
 
Robert Giuliano
KB8RCO




From: "'Lynn W Deffenbaugh (Mr)' kj4erj@... [aprsisce]"
To: aprsisce@...
Sent: Monday, January 18, 2016 4:47 PM
Subject: Re: [aprsisce] Interfacing D-PRS to APRSIS32

 
Actually, it looks like they do both, but the APRS-IS feed is handled by javAPRSSrvr.  From http://www.aprs-is.net/DPRSInterface.aspx

Finally, most repeater gateways have javAPRSSrvr installed to provide gating of D-STAR positions to APRS-IS. To make use of this, set your RPTR2 to your gateway callsign (repeater callsign with a "G" in the eighth character position). This will allow the gateway to see the datastream and gate the D-PRS information to APRS-IS.

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32



On 1/18/2016 2:53 PM, Rob Giuliano kb8rco@... [aprsisce] wrote:
I see. 
I looked up info at:
 
Sounds like they went the wrong way (IMHO).  Computer App to Internet seems more important than computer App to Computer App and take away the internet possibility.
 
 
Robert Giuliano
KB8RCO



From: "'Lynn W Deffenbaugh (Mr)' kj4erj@... [aprsisce]" mailto:aprsisce@...
To: aprsisce@...
Sent: Monday, January 18, 2016 2:32 PM
Subject: Re: [aprsisce] Interfacing D-PRS to APRSIS32

 
I believe the DPRS app actually emulates an APRS-IS server, not an APRS-IS client given that Bob was connecting TO it from an APRSIS32 instance via the APRS-IS server connection.  As such, offering a local server port on the APRSIS32 instance won't work for him.

BUT, APRSISCE/32 supports a receive-only outbound connection to APRS-IS-type servers.  This is done under the (current) port type of CWOP.  So to accomplish what Bob wants to do, simply configure a CWOP-type port to point to the IP address and port of the DPRS server and it should receive the APRS-formatted packets from DPRS.

Note that these packets will only show up on the APRSIS32 instance that is connected to the DPRS server.  But if DPRS supports multiple concurrent connections, you can configure any and all APRSIS32 instances that have TCP/IP connectivity to the DPRS-running machine and they should all receive the incoming packets.

If I've missed the mark on DPRS, please provide a link to a description of its capabilities and I'll have another go at it.

Of course, you'll want to set this up NOW and verify that the DPRS stations are doing what you'd want them to do so we have time to iterate before the upcoming event.

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

PS.  See also: http://aprsisce.wikidot.com/what-am-i-missing

On 1/18/2016 2:12 PM, Rob Giuliano kb8rco@... [aprsisce] wrote:
Can I assume DPRS is an app for the computer which gets data from the D-Star/DPRS radio and delivers it out an IP port?
 
If so, give it a local one from APRSIS32 instance.  MUST BE DEVELOPMENT VERSION!!!
 
>Configure >Ports >New Port >IS-Server        (Can also use Local-Server)
    Name:     DPRS
    Type:      TCP/IP
 
   IP:           127.0.0.1 (hostname of localhost or the real IP of your network card)
   Port:        14551
 
On the DPRS app it should be the same as with the before server: 127.0.0.1:14551. 
  The DPRS app should connect to the local server and your internet connection can still exist.
  The status at top left should read DPRS OK 1/16 (or something like that) when the DPRS connects.
 
Your main APRSIS pot can still connect to the internet.
 
Robert Giuliano
KB8RCO




From: mailto:af9w@...[aprsisce] mailto:aprsisce@...
To: aprsisce@...
Sent: Monday, January 18, 2016 1:47 PM
Subject: [aprsisce] Interfacing D-PRS to APRSIS32

 
We have an event every February called the 24 Hours in the Old Pueblo.  It is a 24 hour mountain bike endurance race on a 16 mile course in the desert with very limited internet access.  We use APRS and APRSIS32 (local SAR standard)  to track the location of our rover stations and to mark the location of any accidents.  Some accidents occur on single track trail where they can be located only by foot patrol.  Some foot patrol people have APRS capable HT's like VX-8 and D72.  I set up an RF only APRSIS32 client at Net Control and we have a couple of D710's in digipeating mode around the course.  This way we can get a good location on the accident.

Some rovers do not have APRS capable HT's but do have DPRS capable D-Star radios.  I have set up DPRS attached to my D-Star mobile radio and can successfully gate packets from my D-Star GPS equipped radio to aprs.fi (AF9W-8).   

Since we don't use the internet at this location I wanted to interface DPRS to APRSIS32.  DPRS outputs APRS-IS format packets on port 14551.  If I change the APRSIS32 APRS-IS port to use IP 127.0.0.1 and Port 14551 then packets received by D-PRS are properly displayed on APRSIS32.   This will work fine for our February event but I would like to have a more general case for other events, i.e. APRS-IS and DPRS at the same time.  

To make a long story short, is there a way to have to APRS-IS format ports open at the same time?  I have tried to create both Simply KISS ports and TEXT ports but neither work. 

Bob AF9W








7381 - 7400 of 35886