From scott at opentrac.org Tue Jun 2 12:30:39 2020 From: scott at opentrac.org (Scott Miller) Date: Tue, 2 Jun 2020 09:30:39 -0700 Subject: [aprssig] aprssig Digest, Vol 191, Issue 24 In-Reply-To: References:

Message-ID: <633ca6a8-5636-9567-f2af-045dc232cc29@opentrac.org> No need for swearing. If you don't want to be on the mailing list, follow the unsubscribe link. 73, Scott N1VG On 5/31/2020 1:30 PM, luis ramos abad wrote: > No mande mierda, no me interesa > > El dom., 31 may. 2020 17:00,

> escribi?: > > Send aprssig mailing list submissions to > aprssig at lists.tapr.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org > or, via email, send a message with subject or body 'help' to > aprssig-request at lists.tapr.org > > You can reach the person managing the list at > aprssig-owner at lists.tapr.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of aprssig digest..." > Today's Topics: > > ? ?1. Re: HF APRS igates on fldigi - Another APRS Client That Works > ? ? ? (Stephen H. Smith) > > > > ---------- Forwarded message ---------- > From:?"Stephen H. Smith" > > To:?TAPR APRS Mailing List > > Cc: > Bcc: > Date:?Sat, 30 May 2020 17:23:18 -0400 > Subject:?Re: [aprssig] HF APRS igates on fldigi - Another APRS > Client That Works > ? I have just finished testing another APRS client app that works > with FLdigi > to send APRS posits over FLdigi modes such as MFSK16. > > A fairly new APRS program "PinPoint APRS" supports the > KISS-over-IP interface > provided by FLdigi.? ?I have tested it using an Acer netbook and > Yaesu FT-891 > to transmit into to my 60-meter igate.? It works. > > I have added a new page showing configuration for PinPoint to my > FLdigi APRS > pages at: > > > > ______________________________________________________________________ > Stephen H. Smith? ? wa8lmf (at) aol.com > Skype:? ? ? ? WA8LMF > EchoLink:? Node #? 14400? [Think bottom of the 2-meter band] > Home Page: http://wa8lmf.net > > -----? ?NEW!? ? 60-Meter APRS!? ?HF NVIS APRS Igate Now Operating? > ------ > ? ? > > > > 11 Copies of UIview in Action on One Computer! > Live Off-The-Air APRS Activity Maps > ? ? > > Long-Range APRS on 30 Meters HF > ? ? > > > > _______________________________________________ > aprssig mailing list > aprssig at lists.tapr.org > http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org > > > _______________________________________________ > aprssig mailing list > aprssig at lists.tapr.org > http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruninga at usna.edu Mon Jun 8 16:06:58 2020 From: bruninga at usna.edu (Robert Bruninga) Date: Mon, 8 Jun 2020 16:06:58 -0400 Subject: [aprssig] APRS speed and Cosine Rule? Message-ID: <9a1ab6dff6d6d1d78cef876d5d7e056c@mail.gmail.com> APRS speed related? Have cop radars implemented the Cosine rule? IE, it should be possible to include a magnetic compass in a handheld radar gun and to initialize it in the direction perpendicular to the road with just a button push... Then the gun can display the actual speed using the cosine rule as the cop sweeps to keep up with your car, (or statically when the cop is at an angle to the line of approach) and not just the relative speed (which approaches zero) as the car goes past the perpendicular point. Curious as to whether I need to consider this when speeding past a radar... Bob, WB4APR From bruninga at usna.edu Mon Jun 8 16:17:00 2020 From: bruninga at usna.edu (Robert Bruninga) Date: Mon, 8 Jun 2020 16:17:00 -0400 Subject: [aprssig] APRS proposed 3 Jan 1991 Message-ID: Cleaning out my lab of 30 years, I found a letter dated 3 Jan 1991 that I sent to 15 Packet people I knew at the time (Mostly AMRAD).... W3IWI, W4RI, ARRL, K1HTV, N4QQ, WB4OIQ, K8MMO, AMRAD, W0RLI, N2GTE, W7HR, N6NKF, G3ZCZ, N4HY, NK6K... It proposed a specification for an Automatic Packet Location System (APLS). Later in 1992, I realized I could change one letter to match my call... APRS. Just a bit of history.. buried under tons of old paper and junk... Hummh... further digging revealed 15 copies and 15 blank envelopes with just a call on them. I guess I never mailed it. (Though I probably sent it out at the time to the local AMRAD BBS)... Bob WB4APR From cq.kg6o at gmail.com Mon Jun 8 17:08:00 2020 From: cq.kg6o at gmail.com (Chris Hoffman) Date: Mon, 8 Jun 2020 14:08:00 -0700 Subject: [aprssig] APRS speed and Cosine Rule? In-Reply-To: <9a1ab6dff6d6d1d78cef876d5d7e056c@mail.gmail.com> References: <9a1ab6dff6d6d1d78cef876d5d7e056c@mail.gmail.com> Message-ID: Every Law Enforcement Department is different, but cosine compensation is probably not as important as many other features available to law enforcement these days, Bob: https://www.lasertech.com/LaserSoft-SpeedCapture-App.aspx Perhaps, one day, we'll be 'lucky' enough to have the complete telemetry and video captured by the arresting officer's device streamed by the patrol unit, through their central collection facility, to our own smart phone and/or in-car smart AV device(s) in real-time. That way, as our car's dashboard lights up to alert us that we have been caught speeding, with a video of ourselves in the act and a small notice that a fine has been posted to our vehicle registration number at the DMV should we choose not to avail ourselves of the automated justice system to contest the resulting ticket. the ID of which is also flashing in the video output we can wave at ourselves... if only to gauge the amount of delay in the stream. /ch N6QR Oh... and always be ready to compare the vehicle's onboard sensor package readings to that reported from the patrol unit's detectors, should we want to suggest that one or the other be calibrated more closely as we pay the fine. On Mon, Jun 8, 2020 at 1:07 PM Robert Bruninga wrote: > APRS speed related? > > Have cop radars implemented the Cosine rule? IE, it should be possible to > include a magnetic compass in a handheld radar gun and to initialize it in > the direction perpendicular to the road with just a button push... > > Then the gun can display the actual speed using the cosine rule as the cop > sweeps to keep up with your car, (or statically when the cop is at an > angle to the line of approach) and not just the relative speed (which > approaches zero) as the car goes past the perpendicular point. > > Curious as to whether I need to consider this when speeding past a > radar... > > Bob, WB4APR > > _______________________________________________ > aprssig mailing list > aprssig at lists.tapr.org > http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric at aehe.us Tue Jun 9 01:08:56 2020 From: eric at aehe.us (Eric H. Christensen) Date: Tue, 09 Jun 2020 05:08:56 +0000 Subject: [aprssig] Generating Weather Alerts from NWR Message-ID: <_5uAnameXLa2h9PtBi92rJ5WxjFyPDd73XgM3QtxBv2pglJa3EAC6y7-SszpTWWYY_oYsMOAwBG6oh5NCOKhYIb9L45IywB3vHzVfnU3Jiw=@aehe.us> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I've wanted a way to transmit weather alert packets on APRS, locally, without the need for an Internet connection (think disaster conditions or other situations where having an Internet connection is just too hard) or if/when the WXSVR is unavailable. I really like the idea of using APRS as a common operating picture of what's happening around you and seeing real-time weather alerts on your screen is a great safety feature. After talking it over with a friend of mine, I think I've come up with an idea that might just work (again, specifically for local use). If a station had some sort of receiver listening to the local NOAA Weather Radio (NWR)[0] then they would receive the Specific Area Message Encoding (SAME)[1] alert for many (most, all?) of the advisories that we care about in real-time, over the air. Decoding the SAME packet looks something like this: ZCZC-ORG-EEE-PSSCCC+TTT-JJJHHMM-LLLLLLLL Where: ZCZC is the header ORG is the type of originator of the message (EAS, CIV, WXR, PEP) EEE is the event type PSSCCCC is the geographic code (FIPS) (up to (and including?) 31 FIPS codes can be included) TTT is the purge time JJJHHMM is the origination time of the advisory LLLLLLLL is the originator of the message Parsing all that information (omitting the header and originator type) we have all the information needed to create our alert message[2][3]. CWAPID:NWS-TTTTT:DDHHMMz,ADVISETYPE,zes{seq# Where: CWAPID is the NWS office and product code (LLLLLLLL and EEE) TTTTT is the type of message (ADVIS,WARN ,WATCH) (EEE) DDHHMMz is the expiration date-time group (factored based on JJJHHMM and TTT) ADVISETYPE is the advisory type (SVRTSM, etc) (EEE) zes is the geographic code used to identify the county/area (PSSCCC) seq# is the sequence number (factored based on JJJHHMM) We can even generate bulletins that can be transmitted using plain language for people to read (think "NWS has issued a Tornado Warning for Orange Co until 19:30."). I'm not sure if anyone has worked on or thought of doing this but it doesn't seem too difficult to do. My friend Kevin, N8VNR, has started a project[4] that decodes the SAME alert once it has been received using Multimon-ng. Using this code, all that would need to be done would be to map the FIPS codes to the county (and marine) codes and create a table that defines what each event code (EEE) should be (TTTTT and ADVISETYPE). Of course, there would need to be some sort of method for transmitting these packets onto RF as well as checking their validity prior to their release (lint anyone?). Again, this is in keeping APRS local, so with NWR broadcasts only covering a few counties at a time, each station would be self-limiting and full control over what areas and event types should be given. Thoughts? 73, Eric WG3K [0] https://www.weather.gov/nwr/ [1] https://web.archive.org/web/20190621022301/https://www.nws.noaa.gov/directives/sym/pd01017012curr.pdf [2] http://www.aprs.org/doc/APRS101.PDF (Page 74) [3] http://www.aprs-is.net/wx/ [4] https://github.com/nivex/dsame -----BEGIN PGP SIGNATURE----- Version: ProtonMail wsFcBAEBCAAGBQJe3xllAAoJEIB2q94CS7PRDn4QAMxW71Bw/2JqpuX7J59u k4hLv8JEeo/yBvUdYmXsk4fw+FHNzW6diacAfqh9wa3/ZJaByffyrM0HnVnE 7iuw7Fcy4m1drIYwNnxrO5tITFlBKjaXcB7BLt2sGMB8FR4O0hj09HcoAY+u Wpd/+9FHWOkSoPYHrjOKZ6xDIU6ULCQN4W1po1L7geDSBUTYSHt6d6AIZSE7 1fIkWKuwnIPRn1dR3vqEqn9hkVA+zi+4Zmpo1k0RGBlmoGmWWX0NcN4LXHnx zTAuyYgaGFvG6qY4FypP10FkF6feRPWNgRii8BxE3Lpbsbvt1IGMCr6GyUiU rZoXypTAAKw1i92yggglFJOgB2I05Aj9L6s3Uhl7R2Zecz7Cvzx9m0z063LX FCVS0Fiqvz7KiNgvvxNqHQIJ7FH45Y2kal8fV7LVhtQJGpTZpGWZpEYwcnyC skawPgoqnmhbvqSAXeUpe7946WhkO22AbaKT2hMolxe/hQM8RQIteKXBD0f/ 0fWFac51upVUsKraroXvaGdqe3pke8JqSZenKT7mt6jjEhKBD8XdUC2cc3iE G/8RtHHx6gJCjC0tp7Uv2dUMjZLrc2TfDl/84i1JD471T7wqFcAlsNnDklqb F0gSv2w56cxubMF6aguiGuwWunUuK7hmimDsVNyei7mHafKtsL/iOMceupuv Bnoh =nnSY -----END PGP SIGNATURE----- From wa7skg at wa7skg.com Tue Jun 9 02:03:52 2020 From: wa7skg at wa7skg.com (wa7skg) Date: Mon, 8 Jun 2020 23:03:52 -0700 Subject: [aprssig] Generating Weather Alerts from NWR In-Reply-To: <_5uAnameXLa2h9PtBi92rJ5WxjFyPDd73XgM3QtxBv2pglJa3EAC6y7-SszpTWWYY_oYsMOAwBG6oh5NCOKhYIb9L45IywB3vHzVfnU3Jiw=@aehe.us> References: <_5uAnameXLa2h9PtBi92rJ5WxjFyPDd73XgM3QtxBv2pglJa3EAC6y7-SszpTWWYY_oYsMOAwBG6oh5NCOKhYIb9L45IywB3vHzVfnU3Jiw=@aehe.us> Message-ID: <3d748915-505f-7330-6472-1303c5dfab41@wa7skg.com> The EAS is designed for both radio and TV. As such, there are already decoders which generate a crawl for TV that will go across the bottom of the screen on a TV channel. So, nothing new about the philosophy. They basically decode the duck farts into a text string and feed it into a character generator for the video. It seems to me a similar thing should be doable for an APRS bulletin. However, there has been much debate regarding the "retransmission" of EAS alerts over ham radio. Not sure if this actually falls into the same category as hooking up a receiver to an EAS decoder and feeding it into a local repeater. This seems more like feeding the data from your own weather station into the system. I'd be interested in seeing such a system in an affordable package for this purpose. It would entail a software modem able to decode the duck farts and a little logic to parse the data to utilize your desired products. Good use of an RPi0. Michael WA7SKG Eric H. Christensen via aprssig wrote on 6/8/20 10:08 PM: > > I've wanted a way to transmit weather alert packets on APRS, locally, without the need for an Internet connection (think disaster conditions or other situations where having an Internet connection is just too hard) or if/when the WXSVR is unavailable. I really like the idea of using APRS as a common operating picture of what's happening around you and seeing real-time weather alerts on your screen is a great safety feature. After talking it over with a friend of mine, I think I've come up with an idea that might just work (again, specifically for local use). > > If a station had some sort of receiver listening to the local NOAA Weather Radio (NWR)[0] then they would receive the Specific Area Message Encoding (SAME)[1] alert for many (most, all?) of the advisories that we care about in real-time, over the air. Decoding the SAME packet looks something like this: > > ZCZC-ORG-EEE-PSSCCC+TTT-JJJHHMM-LLLLLLLL > > Where: > ZCZC is the header > ORG is the type of originator of the message (EAS, CIV, WXR, PEP) > EEE is the event type > PSSCCCC is the geographic code (FIPS) (up to (and including?) 31 FIPS codes can be included) > TTT is the purge time > JJJHHMM is the origination time of the advisory > LLLLLLLL is the originator of the message > > Parsing all that information (omitting the header and originator type) we have all the information needed to create our alert message[2][3]. > > CWAPID:NWS-TTTTT:DDHHMMz,ADVISETYPE,zes{seq# > > Where: > CWAPID is the NWS office and product code (LLLLLLLL and EEE) > TTTTT is the type of message (ADVIS,WARN ,WATCH) (EEE) > DDHHMMz is the expiration date-time group (factored based on JJJHHMM and TTT) > ADVISETYPE is the advisory type (SVRTSM, etc) (EEE) > zes is the geographic code used to identify the county/area (PSSCCC) > seq# is the sequence number (factored based on JJJHHMM) > > We can even generate bulletins that can be transmitted using plain language for people to read (think "NWS has issued a Tornado Warning for Orange Co until 19:30."). > > I'm not sure if anyone has worked on or thought of doing this but it doesn't seem too difficult to do. My friend Kevin, N8VNR, has started a project[4] that decodes the SAME alert once it has been received using Multimon-ng. Using this code, all that would need to be done would be to map the FIPS codes to the county (and marine) codes and create a table that defines what each event code (EEE) should be (TTTTT and ADVISETYPE). Of course, there would need to be some sort of method for transmitting these packets onto RF as well as checking their validity prior to their release (lint anyone?). > > Again, this is in keeping APRS local, so with NWR broadcasts only covering a few counties at a time, each station would be self-limiting and full control over what areas and event types should be given. > > Thoughts? > > 73, > Eric WG3K > > [0] https://www.weather.gov/nwr/ > [1] https://web.archive.org/web/20190621022301/https://www.nws.noaa.gov/directives/sym/pd01017012curr.pdf > [2] http://www.aprs.org/doc/APRS101.PDF (Page 74) > [3] http://www.aprs-is.net/wx/ > [4] https://github.com/nivex/dsame > From info at wirelessmapping.com Tue Jun 9 09:35:44 2020 From: info at wirelessmapping.com (Brian Webster) Date: Tue, 9 Jun 2020 09:35:44 -0400 Subject: [aprssig] Generating Weather Alerts from NWR In-Reply-To: <3d748915-505f-7330-6472-1303c5dfab41@wa7skg.com> References: <_5uAnameXLa2h9PtBi92rJ5WxjFyPDd73XgM3QtxBv2pglJa3EAC6y7-SszpTWWYY_oYsMOAwBG6oh5NCOKhYIb9L45IywB3vHzVfnU3Jiw=@aehe.us> <3d748915-505f-7330-6472-1303c5dfab41@wa7skg.com> Message-ID: <157b01d63e62$e0e799c0$a2b6cd40$@wirelessmapping.com> These projects might be of some help: https://www.rtl-sdr.com/decoding-emwin-weather-information-vhf-rebroadcasts- with-an-rtl-sdr/ https://www.rtl-sdr.com/?s=EMWIN http://usradioguy.com/goes-satellite-imagery-reception/ http://www.emwin.net/ http://open-emwin.sourceforge.net/ Thank you, Brian N2KGC -----Original Message----- From: aprssig [mailto:aprssig-bounces at lists.tapr.org] On Behalf Of wa7skg Sent: Tuesday, June 9, 2020 2:04 AM To: aprssig at lists.tapr.org Subject: Re: [aprssig] Generating Weather Alerts from NWR The EAS is designed for both radio and TV. As such, there are already decoders which generate a crawl for TV that will go across the bottom of the screen on a TV channel. So, nothing new about the philosophy. They basically decode the duck farts into a text string and feed it into a character generator for the video. It seems to me a similar thing should be doable for an APRS bulletin. However, there has been much debate regarding the "retransmission" of EAS alerts over ham radio. Not sure if this actually falls into the same category as hooking up a receiver to an EAS decoder and feeding it into a local repeater. This seems more like feeding the data from your own weather station into the system. I'd be interested in seeing such a system in an affordable package for this purpose. It would entail a software modem able to decode the duck farts and a little logic to parse the data to utilize your desired products. Good use of an RPi0. Michael WA7SKG Eric H. Christensen via aprssig wrote on 6/8/20 10:08 PM: > > I've wanted a way to transmit weather alert packets on APRS, locally, without the need for an Internet connection (think disaster conditions or other situations where having an Internet connection is just too hard) or if/when the WXSVR is unavailable. I really like the idea of using APRS as a common operating picture of what's happening around you and seeing real-time weather alerts on your screen is a great safety feature. After talking it over with a friend of mine, I think I've come up with an idea that might just work (again, specifically for local use). > > If a station had some sort of receiver listening to the local NOAA Weather Radio (NWR)[0] then they would receive the Specific Area Message Encoding (SAME)[1] alert for many (most, all?) of the advisories that we care about in real-time, over the air. Decoding the SAME packet looks something like this: > > ZCZC-ORG-EEE-PSSCCC+TTT-JJJHHMM-LLLLLLLL > > Where: > ZCZC is the header > ORG is the type of originator of the message (EAS, CIV, WXR, PEP) > EEE is the event type > PSSCCCC is the geographic code (FIPS) (up to (and including?) 31 FIPS codes can be included) > TTT is the purge time > JJJHHMM is the origination time of the advisory > LLLLLLLL is the originator of the message > > Parsing all that information (omitting the header and originator type) we have all the information needed to create our alert message[2][3]. > > CWAPID:NWS-TTTTT:DDHHMMz,ADVISETYPE,zes{seq# > > Where: > CWAPID is the NWS office and product code (LLLLLLLL and EEE) > TTTTT is the type of message (ADVIS,WARN ,WATCH) (EEE) > DDHHMMz is the expiration date-time group (factored based on JJJHHMM and TTT) > ADVISETYPE is the advisory type (SVRTSM, etc) (EEE) > zes is the geographic code used to identify the county/area (PSSCCC) > seq# is the sequence number (factored based on JJJHHMM) > > We can even generate bulletins that can be transmitted using plain language for people to read (think "NWS has issued a Tornado Warning for Orange Co until 19:30."). > > I'm not sure if anyone has worked on or thought of doing this but it doesn't seem too difficult to do. My friend Kevin, N8VNR, has started a project[4] that decodes the SAME alert once it has been received using Multimon-ng. Using this code, all that would need to be done would be to map the FIPS codes to the county (and marine) codes and create a table that defines what each event code (EEE) should be (TTTTT and ADVISETYPE). Of course, there would need to be some sort of method for transmitting these packets onto RF as well as checking their validity prior to their release (lint anyone?). > > Again, this is in keeping APRS local, so with NWR broadcasts only covering a few counties at a time, each station would be self-limiting and full control over what areas and event types should be given. > > Thoughts? > > 73, > Eric WG3K > > [0] https://www.weather.gov/nwr/ > [1] https://web.archive.org/web/20190621022301/https://www.nws.noaa.gov/directiv es/sym/pd01017012curr.pdf > [2] http://www.aprs.org/doc/APRS101.PDF (Page 74) > [3] http://www.aprs-is.net/wx/ > [4] https://github.com/nivex/dsame > _______________________________________________ aprssig mailing list aprssig at lists.tapr.org http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org From kg4wsv at gmail.com Tue Jun 9 10:41:57 2020 From: kg4wsv at gmail.com (Jason KG4WSV) Date: Tue, 9 Jun 2020 09:41:57 -0500 Subject: [aprssig] Generating Weather Alerts from NWR In-Reply-To: <_5uAnameXLa2h9PtBi92rJ5WxjFyPDd73XgM3QtxBv2pglJa3EAC6y7-SszpTWWYY_oYsMOAwBG6oh5NCOKhYIb9L45IywB3vHzVfnU3Jiw=@aehe.us> References: <_5uAnameXLa2h9PtBi92rJ5WxjFyPDd73XgM3QtxBv2pglJa3EAC6y7-SszpTWWYY_oYsMOAwBG6oh5NCOKhYIb9L45IywB3vHzVfnU3Jiw=@aehe.us> Message-ID: On Tue, Jun 9, 2020 at 12:09 AM Eric H. Christensen via aprssig < aprssig at lists.tapr.org> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > I've wanted a way to transmit weather alert packets on APRS, locally, > without the need for an Internet connection (think disaster conditions or > other situations where having an Internet connection is just too hard) or > if/when the WXSVR is unavailable. > Me too. The SI4707 is a combined receiver/modem for decoding SAME data. Sparkfun used to have a breakout board but it's no longer available. The 4707 IC is available from Digikey (~US$18 quantity one). There are SAME decoder circuits using the XR2211 ( e.g. https://hackaday.com/2012/07/27/decoding-noaa-weather-radio-with-an-arduino ). I think I used the wayback machine to find the files since they are no longer available on the original web site. Seems that hardware solutions have fallen out of favor and the cool kids are playing with SDR. The solutions I've seen involving the inexpensive RTL-SDR involve sending received audio to multimon-ng. I hadn't heard of the EMWIN terrestrial retransmission on VHF. How's the coverage? -Jason kg4wsv -------------- next part -------------- An HTML attachment was scrubbed... URL: From rustyb78 at yahoo.com Tue Jun 9 11:15:15 2020 From: rustyb78 at yahoo.com (Rusty Bryant) Date: Tue, 9 Jun 2020 15:15:15 +0000 (UTC) Subject: [aprssig] APRS speed and Cosine Rule? In-Reply-To: <9a1ab6dff6d6d1d78cef876d5d7e056c@mail.gmail.com> References: <9a1ab6dff6d6d1d78cef876d5d7e056c@mail.gmail.com> Message-ID: <2061169582.1121576.1591715715152@mail.yahoo.com> Bob, If you want me to keep you safe I'll say YES, but the reality is, most radar units in police cars do not use a cosine rule. Part of our training is that we should keep a 10 degree or less angle between our unit and the target.? But, any increase in angle will only benefit the suspect.? If they are going 30 mph over the speed limit and our radar indicates that you are only going 20mph over the limit, then you just got away with the 10mpg delta. Just remember this, when you double your speed, you quadruple the impact force if you crash. Speed Kills! Rusty WB4BSD On Monday, June 8, 2020, 4:07:49 PM EDT, Robert Bruninga wrote: APRS speed related? Have cop radars implemented the Cosine rule?? IE, it should be possible to include a magnetic compass in a handheld radar gun and to initialize it in the direction perpendicular to the road with just a button push... Then the gun can display the actual speed using the cosine rule as the cop sweeps to keep up with your car, (or statically when the cop is at an angle to the line of approach) and not just the relative speed (which approaches zero) as the car goes past the perpendicular point. Curious as to whether I need to consider this when speeding past a radar... Bob, WB4APR _______________________________________________ aprssig mailing list aprssig at lists.tapr.org http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruninga at usna.edu Tue Jun 9 11:20:34 2020 From: bruninga at usna.edu (Robert Bruninga) Date: Tue, 9 Jun 2020 11:20:34 -0400 Subject: [aprssig] APRS speed and Cosine Rule? In-Reply-To: <2061169582.1121576.1591715715152@mail.yahoo.com> References: <9a1ab6dff6d6d1d78cef876d5d7e056c@mail.gmail.com> <2061169582.1121576.1591715715152@mail.yahoo.com> Message-ID: Thanks! Cosine of 10 degrees is 98.5% so that is very little error. That means only about 1 MPH difference at 60 MPH? Thanks Bob *From:* Rusty Bryant *Sent:* Tuesday, June 9, 2020 11:15 AM *To:* aprssig ; Robert Bruninga *Cc:* wb4apr at aprs.org *Subject:* Re: [aprssig] APRS speed and Cosine Rule? Bob, If you want me to keep you safe I'll say YES, but the reality is, most radar units in police cars do not use a cosine rule. Part of our training is that we should keep a 10 degree or less angle between our unit and the target. But, any increase in angle will only benefit the suspect. If they are going 30 mph over the speed limit and our radar indicates that you are only going 20mph over the limit, then you just got away with the 10mpg delta. Just remember this, when you double your speed, you quadruple the impact force if you crash. Speed Kills! Rusty WB4BSD On Monday, June 8, 2020, 4:07:49 PM EDT, Robert Bruninga wrote: APRS speed related? Have cop radars implemented the Cosine rule? IE, it should be possible to include a magnetic compass in a handheld radar gun and to initialize it in the direction perpendicular to the road with just a button push... Then the gun can display the actual speed using the cosine rule as the cop sweeps to keep up with your car, (or statically when the cop is at an angle to the line of approach) and not just the relative speed (which approaches zero) as the car goes past the perpendicular point. Curious as to whether I need to consider this when speeding past a radar... Bob, WB4APR _______________________________________________ aprssig mailing list aprssig at lists.tapr.org http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruninga at usna.edu Thu Jun 11 14:28:19 2020 From: bruninga at usna.edu (Robert Bruninga) Date: Thu, 11 Jun 2020 14:28:19 -0400 Subject: [aprssig] FW: APRS Question (Drone tracking of downed balloons) Message-ID: <378b0711845aae4c6a26a995278ad1a9@mail.gmail.com> Kameron KG7VSN asked a question about using a RC aircraft to act as a final digi for a balloon once it has landed. But I?d take it one step further. Put the APRS digipeater on a drone and also listen for the LAT/LON of the balloon. Then launch the drone once the balloon begins to descend. Program the drone to always go to the balloon position and maintain 1000 feet altitude until told otherwise. (or whatever is the legal height for drones?) Neat! Bob, WB4APR *From:* Robert Bruninga *Sent:* Thursday, June 11, 2020 2:23 PM *To:* Kameron Markham ; wb4apr at amsat.org *Cc:* Robert Bruninga *Subject:* RE: APRS Question Great idea I think. Yes, avoid using WIDE1-1. But using SKY1-1 is perfect if you name the digipeating alias in the RC plane to be SKY1-1. You could just nake it SKY and then digipeat via SKY, but I like keeping the SKY1-1 convention? Let everyone know how well it works. In fact, a DRONE couild be pretty good atr this too. In fact, Program the drone to GO to the LAT/LONG of the balloon. And hover there! Bob *From:* Kameron Markham *Sent:* Wednesday, June 10, 2020 4:23 PM *To:* wb4apr at amsat.org *Subject:* APRS Question Hi, I have scoured the internet on this question and haven't found any guidance. I'm part of a high altitude balloon club operating out of the auburn school district in the seattle area. When recovering balloons, the challenge we run into is recovering the balloons once they land. They frequently land in little dips in the earth, or far from roads, such that they cannot be heard by any of our tracking vehicles. The idea that I had was to take a picoAPRS radio in digipeater mode and fly it on an RC plane over the last known area until it relays a position to the terrestrial radios. The problem is, we would then have to program the balloon to use some kind of digi path. I know that we shouldn't fly with any widen-n paths over a certain altitude, but the tinytrak3 radios we use on the balloons cannot switch between no digi paths and using digi paths based on the altitude. I was wondering if the protocol supports using a "custom" digi path like sky1-1 or some other string that would allow for our flying digipeater to behave like a wide1-1 fill in digipeater without having the balloons key up every fill-in repeater in the state. The idea is to use something that will be ignored by all the ground stations that hear it, but have a digipeater programmed to respond to it and rebroadcast it. That said, I also don't want to cause interference or confusion on the network. Thanks, -- Kameron Markham [KG7VSN] Washington State University (Tri-Cities) (253)347-3004 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wa8lmf2 at aol.com Thu Jun 11 21:16:51 2020 From: wa8lmf2 at aol.com (Stephen H. Smith) Date: Thu, 11 Jun 2020 21:16:51 -0400 Subject: [aprssig] FW: APRS Question (Drone tracking of downed balloons) In-Reply-To: <378b0711845aae4c6a26a995278ad1a9@mail.gmail.com> References: <378b0711845aae4c6a26a995278ad1a9@mail.gmail.com> Message-ID: <9518fc2b-99fc-b259-41e2-11cdf0658454@aol.com> On 6/11/2020 2:28 PM, Robert Bruninga wrote: > Kameron KG7VSN asked a question about using a RC aircraft to act as a final > digi for a balloon once it has landed.? But I?d take it one step further. > > Put the APRS digipeater on a drone and also listen for the LAT/LON of the > balloon.? Then launch the drone once the balloon begins to descend.? Program > the drone to always go to the balloon position and maintain 1000 feet altitude > until told otherwise.? (or whatever is the legal height for drones?) > > Maximum legal height for civilian-type drones is only 400 feet AGL. More importantly, you have to maintain visual contact with the drone at all times; i.e. you can't send it many miles away from your own control point. The real question is how would you mount a digi on a drone? The average consumer drone has next to no additional lifting capacity. Like a space rocket where 80+ percent of the liftoff weight is fuel, about 2/3rds of the weight of the typical drone is battery pack. I have been thinking about putting a Big Red Bee APRS tracker on my Autel EVO which would be less than an ounce added weight. But an APRS digi would require a full TX/RX radio, a TNC-like device of some sort sor and a battery system. Maybe one of those discontinued Alinco credit-card-sized QRP 2-meter rigs and a TT4.... Most serious consumer drones (DJI, Autel, Parrot, etc) are powered by proprietary lithium-ion battery packs with odd voltage outputs. One might also have to factor in some sort of DC-to-DC converter if you want to steal power from the drone's own battery pack. Note that the maximum run time for most of these drones on a fully-charged battery is 15-25 minutes max, even before you start sucking power from the battery pack for other electronic devices. Due to the limited flight time, ou would have to launch the chase drone very close to the end of a balloon flight, just before landing. Note that the drone already has TWO radio systems on board. One for flight control and camera control uplink and engineering data (battery state, altitude, GPS data, etc) downlink. A separate radio provides the live HD or UHD video feed down link. One would have to thoroughly test the EMI/RFI issues before putting a third 2M VHF transmitter onboard. ___________________________________________________________ Stephen H. Smith wa8lmf (at) aol.com Skype: WA8LMF EchoLink: Node # 14400 [Think bottom of the 2-meter band] Home Page: http://wa8lmf.net ----- NEW! 60-Meter APRS! HF NVIS APRS Igate Now Operating ------ 11 Copies of UIview in Action on One Computer! Live Off-The-Air APRS Activity Maps Long-Range APRS on 30 Meters HF From spam8mybrain at yahoo.com Thu Jun 11 21:45:33 2020 From: spam8mybrain at yahoo.com (spam8mybrain) Date: Thu, 11 Jun 2020 21:45:33 -0400 Subject: [aprssig] FW: APRS Question (Drone tracking of downed balloons) References: Message-ID: Here's a silly idea: how about a _tethered_ balloon for your temporary digi? You can use the power cord for the tether, so you don't have to fly battery weight, and you can use thin wire to reduce tether weight and a higher voltage supply on the ground to overcome voltage drop in the tether (like Power over Ethernet). And you don't have to worry about it crashing and being another loss, unlike a drone with a dead battery. You probably can't get it much higher than the drone (given tether weight), but with a nearby location on a high spot, it should be doable. And you can always reel it down, stick it (inflated) into the back of a van to drive somewhere else if the first location doesn?t work. It just increases your helium budget.Just my $.02.Andrew, KA2DDO -------- Original message -------- From: "Stephen H. Smith via aprssig" Date: 6/11/20 21:16 (GMT-05:00) To: TAPR APRS Mailing List Subject: Re: [aprssig] FW: APRS Question (Drone tracking of downed balloons) On 6/11/2020 2:28 PM, Robert Bruninga wrote:> Kameron KG7VSN asked a question about using a RC aircraft to act as a final > digi for a balloon once it has landed.? But I?d take it one step further.> > Put the APRS digipeater on a drone and also listen for the LAT/LON of the > balloon.? Then launch the drone once the balloon begins to descend.? Program > the drone to always go to the balloon position and maintain 1000 feet altitude > until told otherwise.? (or whatever is the legal height for drones?)> > Maximum legal height for civilian-type drones is only 400 feet AGL.? More importantly, you have to maintain visual contact with the drone at all times; i.e. you can't send it many miles away from your own control point.The real question is how would you mount a digi on a drone?The average consumer drone has next to no additional lifting capacity. Like a space rocket where 80+ percent of the liftoff weight is fuel, about 2/3rds of the weight of the typical drone is battery pack. I have been thinking about putting a Big Red Bee APRS tracker on my Autel EVO which would be less than an ounce added weight.But an APRS digi would require a full TX/RX radio, a TNC-like device of some sort sor and a battery system.? Maybe one of those discontinued Alinco credit-card-sized QRP 2-meter rigs and a TT4....Most serious consumer drones (DJI, Autel, Parrot, etc) are powered by proprietary lithium-ion battery packs with odd voltage outputs. One might also have to factor in some sort of DC-to-DC converter if you want to steal power from the drone's own battery pack.?? Note that the maximum run time for most of these drones on a fully-charged battery is 15-25 minutes max, even before you start sucking power from the battery pack for other electronic devices.? Due to the limited flight time, ou would have to launch the chase drone very close to the end of a balloon flight, just before landing.Note that the drone already has TWO radio systems on board.? One for flight control and camera control uplink and engineering data (battery state, altitude, GPS data, etc) downlink.? A separate radio provides the live HD or UHD video feed down link.? One would have to thoroughly test the EMI/RFI issues before putting a third 2M VHF transmitter onboard.___________________________________________________________Stephen H. Smith??? wa8lmf (at) aol.comSkype:??????? WA8LMFEchoLink:? Node #? 14400? [Think bottom of the 2-meter band]Home Page:????????? http://wa8lmf.net-----?? NEW!??? 60-Meter APRS!?? HF NVIS APRS Igate Now Operating? ------??? 11 Copies of UIview in Action on One Computer!Live Off-The-Air APRS Activity Maps??? Long-Range APRS on 30 Meters HF??? _______________________________________________aprssig mailing listaprssig at lists.tapr.orghttp://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruninga at usna.edu Fri Jun 12 12:19:22 2020 From: bruninga at usna.edu (Robert Bruninga) Date: Fri, 12 Jun 2020 12:19:22 -0400 Subject: [aprssig] FW: APRS Question (Drone tracking of downed balloons) In-Reply-To: References: Message-ID: <5becc11cfe1c2abc9ab7b94c039a393c@mail.gmail.com> The best thing I liked about this idea is the use of a digi path that does not use WIDEn-N at altitude nor a WIDE1-1 at the end. By making the balloon path be something like ?DRONE? for the entire flight, then it will not bring u p any existing infrastructure, but we can use Drones, or RC aircraft, or tethered balloons, or mobiles with UIDIGI set to DRONE) to provide the final look over the last hill! Bob, WB4APR *From:* aprssig *On Behalf Of *spam8mybrain via aprssig *Sent:* Thursday, June 11, 2020 9:46 PM *To:* TAPR APRS Mailing List *Subject:* Re: [aprssig] FW: APRS Question (Drone tracking of downed balloons) Here's a silly idea: how about a _tethered_ balloon for your temporary digi? You can use the power cord for the tether, so you don't have to fly battery weight, and you can use thin wire to reduce tether weight and a higher voltage supply on the ground to overcome voltage drop in the tether (like Power over Ethernet). And you don't have to worry about it crashing and being another loss, unlike a drone with a dead battery. You probably can't get it much higher than the drone (given tether weight), but with a nearby location on a high spot, it should be doable. And you can always reel it down, stick it (inflated) into the back of a van to drive somewhere else if the first location doesn?t work. It just increases your helium budget. Just my $.02. Andrew, KA2DDO -------- Original message -------- From: "Stephen H. Smith via aprssig" Date: 6/11/20 21:16 (GMT-05:00) To: TAPR APRS Mailing List Subject: Re: [aprssig] FW: APRS Question (Drone tracking of downed balloons) On 6/11/2020 2:28 PM, Robert Bruninga wrote: > Kameron KG7VSN asked a question about using a RC aircraft to act as a final > digi for a balloon once it has landed. But I?d take it one step further. > > Put the APRS digipeater on a drone and also listen for the LAT/LON of the > balloon. Then launch the drone once the balloon begins to descend. Program > the drone to always go to the balloon position and maintain 1000 feet altitude > until told otherwise. (or whatever is the legal height for drones?) > > Maximum legal height for civilian-type drones is only 400 feet AGL. More importantly, you have to maintain visual contact with the drone at all times; i.e. you can't send it many miles away from your own control point. The real question is how would you mount a digi on a drone? The average consumer drone has next to no additional lifting capacity. Like a space rocket where 80+ percent of the liftoff weight is fuel, about 2/3rds of the weight of the typical drone is battery pack. I have been thinking about putting a Big Red Bee APRS tracker on my Autel EVO which would be less than an ounce added weight. But an APRS digi would require a full TX/RX radio, a TNC-like device of some sort sor and a battery system. Maybe one of those discontinued Alinco credit-card-sized QRP 2-meter rigs and a TT4.... Most serious consumer drones (DJI, Autel, Parrot, etc) are powered by proprietary lithium-ion battery packs with odd voltage outputs. One might also have to factor in some sort of DC-to-DC converter if you want to steal power from the drone's own battery pack. Note that the maximum run time for most of these drones on a fully-charged battery is 15-25 minutes max, even before you start sucking power from the battery pack for other electronic devices. Due to the limited flight time, ou would have to launch the chase drone very close to the end of a balloon flight, just before landing. Note that the drone already has TWO radio systems on board. One for flight control and camera control uplink and engineering data (battery state, altitude, GPS data, etc) downlink. A separate radio provides the live HD or UHD video feed down link. One would have to thoroughly test the EMI/RFI issues before putting a third 2M VHF transmitter onboard. ___________________________________________________________ Stephen H. Smith wa8lmf (at) aol.com Skype: WA8LMF EchoLink: Node # 14400 [Think bottom of the 2-meter band] Home Page: http://wa8lmf.net ----- NEW! 60-Meter APRS! HF NVIS APRS Igate Now Operating ------ 11 Copies of UIview in Action on One Computer! Live Off-The-Air APRS Activity Maps Long-Range APRS on 30 Meters HF _______________________________________________ aprssig mailing list aprssig at lists.tapr.org http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruninga at usna.edu Fri Jun 12 12:32:13 2020 From: bruninga at usna.edu (Robert Bruninga) Date: Fri, 12 Jun 2020 12:32:13 -0400 Subject: [aprssig] FW: APRS Question (Drone tracking of downed balloons) In-Reply-To: <9518fc2b-99fc-b259-41e2-11cdf0658454@aol.com> References: <378b0711845aae4c6a26a995278ad1a9@mail.gmail.com> <9518fc2b-99fc-b259-41e2-11cdf0658454@aol.com> Message-ID: <2bd18b1d34a9e6268d64750c1528a024@mail.gmail.com> Good info on the drone technology. Thanks... But the flight does not have to be but a few minutes. And can be done within line of sight. Just drive to the last received position of the balloon as it came down, plus a little bit of estimation and a good sense of altitude (local hill) and launch the drone from there. With the balloon doing a 1 minute APRS packet, (which is now a constant position on the ground), it should not take but a few minutes to get that posit. Besides, its more toys to play with in the field. The TinyTrackerTT4 (cut down from a MTT4B 10W tracker) only weighs 60g and a 9v battery weighs 40g and makes a full function digi with Xcvr. We use these for all of our student satellite projects, but we have re-layed out all the parts onto our own board to make it fit on a 3" square board and without the 10 Watt amp. They mention the 1 Watt Microtrack 1000 as having a transceiver, but it uses the TT3 chip which I don?t thinkn has a packet receiver code? So it cannot act as a digi? Bob -----Original Message----- From: Stephen H. Smith Sent: Thursday, June 11, 2020 9:17 PM To: TAPR APRS Mailing List Subject: Re: [aprssig] FW: APRS Question (Drone tracking of downed balloons) On 6/11/2020 2:28 PM, Robert Bruninga wrote: > Kameron KG7VSN asked a question about using a RC aircraft to act as a > final digi for a balloon once it has landed. But I?d take it one step > further. > > Put the APRS digipeater on a drone and also listen for the LAT/LON of > the balloon. Then launch the drone once the balloon begins to > descend. Program the drone to always go to the balloon position and > maintain 1000 feet altitude until told otherwise. (or whatever is the > legal height for drones?) > > Maximum legal height for civilian-type drones is only 400 feet AGL. More importantly, you have to maintain visual contact with the drone at all times; i.e. you can't send it many miles away from your own control point. The real question is how would you mount a digi on a drone? The average consumer drone has next to no additional lifting capacity. Like a space rocket where 80+ percent of the liftoff weight is fuel, about 2/3rds of the weight of the typical drone is battery pack. I have been thinking about putting a Big Red Bee APRS tracker on my Autel EVO which would be less than an ounce added weight. But an APRS digi would require a full TX/RX radio, a TNC-like device of some sort sor and a battery system. Maybe one of those discontinued Alinco credit-card-sized QRP 2-meter rigs and a TT4.... Most serious consumer drones (DJI, Autel, Parrot, etc) are powered by proprietary lithium-ion battery packs with odd voltage outputs. One might also have to factor in some sort of DC-to-DC converter if you want to steal power from the drone's own battery pack. Note that the maximum run time for most of these drones on a fully-charged battery is 15-25 minutes max, even before you start sucking power from the battery pack for other electronic devices. Due to the limited flight time, ou would have to launch the chase drone very close to the end of a balloon flight, just before landing. Note that the drone already has TWO radio systems on board. One for flight control and camera control uplink and engineering data (battery state, altitude, GPS data, etc) downlink. A separate radio provides the live HD or UHD video feed down link. One would have to thoroughly test the EMI/RFI issues before putting a third 2M VHF transmitter onboard. ___________________________________________________________ Stephen H. Smith wa8lmf (at) aol.com Skype: WA8LMF EchoLink: Node # 14400 [Think bottom of the 2-meter band] Home Page: http://wa8lmf.net ----- NEW! 60-Meter APRS! HF NVIS APRS Igate Now Operating ------ 11 Copies of UIview in Action on One Computer! Live Off-The-Air APRS Activity Maps Long-Range APRS on 30 Meters HF From will at spaceflightsoftware.com Fri Jun 12 13:18:19 2020 From: will at spaceflightsoftware.com (Will Marchant) Date: Fri, 12 Jun 2020 13:18:19 -0400 Subject: [aprssig] FW: APRS Question (Drone tracking of downed balloons) In-Reply-To: <2bd18b1d34a9e6268d64750c1528a024@mail.gmail.com> References: <378b0711845aae4c6a26a995278ad1a9@mail.gmail.com> <9518fc2b-99fc-b259-41e2-11cdf0658454@aol.com> <2bd18b1d34a9e6268d64750c1528a024@mail.gmail.com> Message-ID: <118d7a84-9b38-6c65-8edc-0721a34da418@spaceflightsoftware.com> The http://www.picoaprs.de/index_en.html will digi. It is only 1W but would easily fulfill the "last mile" issue if flown. Anne and I have been using DJI Phantom 4 quadcopters (https://store.dji.com/product/phantom-4-pro-v2?vid=43151 is the new version) to fly payloads for her students. They easily handle small payloads such as this. 73, Will KW4WZ On 6/12/20 12:32 PM, Robert Bruninga wrote: > Good info on the drone technology. Thanks... > > But the flight does not have to be but a few minutes. And can be done > within line of sight. Just drive to the last received position of the > balloon as it came down, plus a little bit of estimation and a good sense of > altitude (local hill) and launch the drone from there. > > With the balloon doing a 1 minute APRS packet, (which is now a constant > position on the ground), it should not take but a few minutes to get that > posit. > > Besides, its more toys to play with in the field. -- Will Marchant, KW4WZ will at spaceflightsoftware.com http://www.spaceflightsoftware.com/will/ From hessu at hes.iki.fi Fri Jun 12 13:26:08 2020 From: hessu at hes.iki.fi (Heikki Hannikainen) Date: Fri, 12 Jun 2020 20:26:08 +0300 (EEST) Subject: [aprssig] FW: APRS Question (Drone tracking of downed balloons) In-Reply-To: <9518fc2b-99fc-b259-41e2-11cdf0658454@aol.com> References: <378b0711845aae4c6a26a995278ad1a9@mail.gmail.com> <9518fc2b-99fc-b259-41e2-11cdf0658454@aol.com> Message-ID: On Thu, 11 Jun 2020, Stephen H. Smith via aprssig wrote: > The real question is how would you mount a digi on a drone? > The average consumer drone has next to no additional lifting capacity. Like a > space rocket where 80+ percent of the liftoff weight is fuel, about 2/3rds of > the weight of the typical drone is battery pack. I have been thinking about > putting a Big Red Bee APRS tracker on my Autel EVO which would be less than > an ounce added weight. The PicoAPRS tracker is 1,8 x 3,3 x 5,6 cm, weighting 44 grams with a battery. It can act as a standalone digipeater. http://www.db1nto.de/index_en.html APRS aside, the Dave M0RPI, one of the main UK High Altitude folks, have used another balloon to relay the positions by the first balloons. With LORA trackers though. (And more recently, ADS-B positions: https://www.youtube.com/watch?v=FgXtPIF2HAw http://www.daveakerman.com/?page_id=2410) - Hessu From wb2osz at comcast.net Sun Jun 14 13:11:20 2020 From: wb2osz at comcast.net (John Langner WB2OSZ) Date: Sun, 14 Jun 2020 13:11:20 -0400 Subject: [aprssig] Generating Weather Alerts from NWR Message-ID: <001f01d6426e$d4221ed0$7c665c70$@comcast.net> Eric wrote: > I've wanted a way to transmit weather alert packets on APRS, locally, > without the need for an Internet connection ... You might find this interesting: EAS SAME to APRS Message Converter https://github.com/wb2osz/eas2aprs From davidf4 at mindspring.com Sun Jun 14 16:00:59 2020 From: davidf4 at mindspring.com (David Flood) Date: Sun, 14 Jun 2020 13:00:59 -0700 Subject: [aprssig] NWS is thinking of "updating" their alerts Message-ID: <000a01d64286$86c61e30$94525a90$@mindspring.com> Posting on Twit and FB: https://twitter.com/NWSSeattle/status/1272250957758369794 Have you ever been confused by all of our Watches, Warnings, and Advisories? Learn more about a proposal to simplify our alerts, and take our brief survey to let us know what you think! LINK: http://surveymonkey.com/r/publichazsimp #HazSimp Dave KD7MYC -------------- next part -------------- An HTML attachment was scrubbed... URL: From k6jq at comcast.net Tue Jun 16 10:55:46 2020 From: k6jq at comcast.net (DANA MYERS) Date: Tue, 16 Jun 2020 07:55:46 -0700 (PDT) Subject: [aprssig] Observations of Packet Test CD Track 2 Message-ID: <991031837.306157.1592319346389@connect.xfinity.com> Hello all, I was "encouraged" to post this here. Back in the idyllic times of 2016, I noticed that Packet Test CD Track 2 doesn't sound right, so I did some objective measuring. Track 2 is supposed to be the 'de-emphasized' version of Track 1. I extracted the same section of inter-packet noise on Track 1 and Track 2, and used Audacity to produce spectrum graphs of both. (if anyone doesn't understand this technique, email me off-list and I'll explain). Track 1 (discriminator output) response is what you'd expect for an NBFM channel, flat-ish out to a few kHz, then IF BW limited: https://drive.google.com/open?id=0B6J9M7BemghDMU9QdWJuQk9kNm8 Track 2 (de-emphasized) has an unexpected -15dB notch at ~3100Hz, but don't left that distract from the real problem - it has a -12dB/octave response from 300Hz to the onset of the notch: https://drive.google.com/open?id=0B6J9M7BemghDYlB1QVFZdWRUUms It's easy to miss that it's -12dB instead of -6dB if you don't look at the Y-axis scale. Track 2 doesn't represent any kind of real-world scenario, and should simply be deleted. In discussing this Stephen on the phone, we lamented that Track 2 was too well-established to correct it now. Stephen has documented well the use of Adobe Audition (IIRC) that just didn't do what it said it was doing. I don't use Track 2 and disregard any test results reported using Track 2, and would encourage others to do the same. For comparison sake, here's my own de-emphasized Track 1 produced using Audacity ( -6dB/octave 300Hz LPF, and a high-pass CTCSS cut filter because that's what real radios do): https://drive.google.com/open?id=0B6J9M7BemghDV0JKaTdmaHdRUWs A real-world example, this is the response of a TM-D700A 1200-baud data output: https://drive.google.com/open?id=0B6J9M7BemghDNjM3dXFWS2VzRzA It has the CTCSS cut HPF at 400Hz. Here's another real-world example, a proper Batwing Motorola Maxtrac 300: https://drive.google.com/open?id=1Oks8g-tJABNML3Ky6cB8ZGe1B2DKMm5R Forgive me for using a wider X-axis scale here, I took this measurement at a different time. 73, Dana K6JQ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruninga at usna.edu Sat Jun 20 09:45:10 2020 From: bruninga at usna.edu (Robert Bruninga) Date: Sat, 20 Jun 2020 09:45:10 -0400 Subject: [aprssig] APRS Op needed at Mt Greylock and Mt Washington In-Reply-To: <3787.1592658653796828490@groups.io> References: <3787.1592658653796828490@groups.io> Message-ID: For the annual Appalachian GOlden Packet Event on 18 July (manning 15 mountains from Maine to Georgia), we have two holes in the 15 Hop packet link. Anyone in those area want to join the fun for about 4 hours (plus travel times)? All you need is a kenwood APRS radio that will digipeat. ---------- Forwarded message --------- Subject: Re: [atgp] Upcoming Event: AT Golden Packet 2020 - Sat, 07/18/2020 Hello ATGP Folks: >From a look at the latest 2020 ATGP spread sheet, linked on Bob's ATGP web site, ( http://aprs.org/at-golden-packet.html ) two observations: 1. Greylock-11 has been removed and so is not man'ed !?! 2. Mt Washington-13 is not man'ed yet !?! This apparently leaves Mt Equinox-12 isolated, without (from past experience) the ability to reach Mt St Joe's or Mt Katahdin to the north, or Sams Point to the south. Thanks, -- Jeff Marden/N1JCM Equnox-12 _._,_._,_ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralphmilnes at gmail.com Sat Jun 20 22:02:09 2020 From: ralphmilnes at gmail.com (Ralph Milnes) Date: Sat, 20 Jun 2020 20:02:09 -0600 Subject: [aprssig] For Sale: USED Peet Bros Weather Station with Ham Radio and TNC for APRS Use Message-ID: I'm getting out of the APRS WX "business" and am looking to sell my used Peet Bros weather station as a package. The package includes an old ICOM IC-25A transceiver (tuneable to 144.39) and a Kantronics KPC 3+ TNC. It's for sale on ebay at https://www.ebay.com/itm/153978383980 until Sunday June 27 I'm selling this as a complete package. I need to get everything out of the garage. I'm not entertaining offers for individual weather station or ham radio components at this time. Ralph Milnes NM5RM -------------- next part -------------- An HTML attachment was scrubbed... URL: From showard at nd.edu Sun Jun 28 19:19:44 2020 From: showard at nd.edu (Scott Howard) Date: Sun, 28 Jun 2020 19:19:44 -0400 Subject: [aprssig] Packet Compressed Sensing Imaging (PCSI) Message-ID: Dear APRS SIG, I'm happy to share a new image transfer method called PCSI that a team of students and I have been developing during quarantine. PCSI is digital (packet based), unconnected multicast (UI frames), compatible with APRS (basically turbo-charged APRS Vision https://www.tapr.org/pdf/DCC1997-APRSvision-WB4APR.pdf), resilient to packet loss (every receiving station can receive a different random set of packets and still reconstruct the entire image), and computationally trivial for the transmitter (8-bit microcontroller can easily construct packets). The goal is to be used with low-power microcontrollers and weak signals (even HF modes) transmitting images when packets will likely be lost. In SSTV and other unconnected digital image modes like SSDV, if the signal is weak or packets are lost, entire sections of the image are distorted or missing. In PCSI, if packets are lost, you still receive the entire image. Every additional packet received (in any order) simply increases image quality. Images take between 1-4 minutes to come in using 1200 baud, which is on par with SSTV. It's all controlled with an easy GUI where you just set your call sign, load your file, then click send. I've used it to transmit images locally between a hamshield KISS system and a kenwood TH-D72a, and between two direwolf systems acoustically through speakers and microphones. Now it's ready for testing in the wild. *Details and usage videos are here:* https://maqifrnswa.github.io/PCSI/ *Windows and Linux binaries* (for TCP or serial port KISS devices) are available here: https://github.com/maqifrnswa/PCSI/releases/tag/v0.0.0 (It should work on Macs too, I just don't have one to build binaries. If you're comfortable with python on Mac, you can also just use the source code.) *Python Source code (everything is open source)*: https://github.com/maqifrnswa/PCSI The method isn't necessarily tied to APRS and can be used over any band or mode, but if you'd like to explore its use for tactical and timely image transmission over APRS (basically the goal of APRS Vision), you can set it to use base91 encoding, use the "{{V" info prefix, and use an appropriate altnet. For now, I've been using the destination address PCSI to indicate that these are PCSI packets. Since this is a specialized group of experts, I'd appreciate any testing and feedback you can give. It's kind of a fun mode - you start watching the entire image come in over time, and as packets arrive, the image comes in to focus. To transmit and receive, you just need any KISS TNC/soundmodem/direwolf/etc. It might be a cool way to send low-res images over lossy and weak HF channels when you don't want to spend bits on FEC (although you could also put FEC on top of this method). Any feature requests, advice, or tips are welcome as well. Backstory: When CoVid-19 shut down universities, students weren't able to continue lab based work. I came up with this project so that undergraduate lab assistants could work remotely while supporting a new educational initiative that my university is pursuing around students developing technology for high altitude balloons. The results are like magic - even receiving 20%-30% of the total bytes of the original image (i.e., 70-80% packet loss) gives high quality images. And it's a good introduction for students to the math behind compressed sensing imaging. There are also other tricks under the hood, like the optional use of chroma compression to increase speed. Cheers and thanks! Scott -- *Scott Howard, PhD* *Associate Professor* Department of Electrical Engineering University of Notre Dame http://ee.nd.edu 574-631-2570 (direct) 574-631-4393 (fax) h ttps://howardphotonics.nd.edu Follow me on Twitter @HowardPhotonics 262 Fitzpatrick Hall Notre Dame, IN 46556 -------------- next part -------------- An HTML attachment was scrubbed... URL: From stanzepa at gmail.com Mon Jun 29 20:02:36 2020 From: stanzepa at gmail.com (Stan Horzepa) Date: Mon, 29 Jun 2020 20:02:36 -0400 Subject: [aprssig] 2020 ARRL/TAPR Digital Communications Conference (DCC) Update Message-ID: The 39th Annual ARRL and TAPR Digital Communications Conference (DCC) will be a virtual conference on September 11 and 12, using Zoom video communications and YouTube video-sharing platforms. Registered DCC attendees participating via Zoom will be able to interact with presenters and other attendees via a chat room as well as raise a virtual hand to ask questions. Go to https://tapr.org/product/dcc-registration/ to register (you don?t need a Zoom account to register). Non-registered DCC attendees can watch the live stream for free on YouTube, however, non-registered DCC attendees will not be able to ask questions or chat. No registration is required for YouTube access (the YouTube URL will be announced and posted on this webpage preceding the DCC). DCC registration is free for TAPR members and $30 for non-members. Members receive a 100% discount at checkout. Go to https://tapr.org/product/dcc-registration/ to register. Non-members who would like to join TAPR and receive the free DCC pass can simply add TAPR membership and DCC registration to their shopping carts. After checkout, they will receive the free DCC pass when their membership is processed. *Call for Papers and Speakers* Technical papers are solicited for presentation at the DCC. Papers will also be published in the Conference Proceedings. Authors do not need to present at the conference to have their papers included in the Proceedings. Submit papers via e-mail to Maty Weinberg, KB1EIB by August 15, 2020. Papers will be published exactly as submitted and authors will retain all rights. Conference papers will be distributed as pdf?s to participants. Printed copies of the papers will be available for sale at Lulu (http TBD). Also, speakers are invited to make presentations on topics of interest without submitting papers for the Conference Proceedings. All speakers and presenters must contact Steve Bible, N7HPR to reserve a slot for your presentation. Indicate whether you need a 15- or 30-minute slot and if you need to present on a specific day (Friday, September 11 or Saturday, September 12). A pre-recorded presentation can be submitted in lieu of a live virtual presentation. Paper and presentation topic areas include, but are not limited to software defined radio (SDR), digital voice, digital satellite communication, digital signal processing (DSP), HF digital modes, adapting IEEE 802.11 systems for Amateur Radio, Global Positioning System (GPS), Automatic Position Reporting System (APRS), Linux in Amateur Radio, AX.25 updates, Internet operability with Amateur Radio networks, TCP/IP networking over Amateur Radio, mesh and peer-to-peer wireless networking, emergency and homeland defense backup digital communications in Amateur Radio. *Lightning Talks* Ad hoc ?lightning talks? on various topics of interest will be announced throughout the DCC. Registered attendees will be able to participate in any lightning talk that whets their appetite. *Hardware and Software Demos* Hardware and software demonstrations will be conducted during the DCC by means of Zoom?s breakout room feature. -------------- next part -------------- An HTML attachment was scrubbed... URL: From spam8mybrain at yahoo.com Mon Jun 29 23:55:49 2020 From: spam8mybrain at yahoo.com (spam8mybrain) Date: Mon, 29 Jun 2020 23:55:49 -0400 Subject: [aprssig] Packet Compressed Sensing Imaging (PCSI) References: Message-ID: Interesting concept. What is the packet transmit rate with your protocol? Can it coexist with other users on the channel by waiting between packets, or will it saturate the channel until the picture is sent? Assuming the Father of APRS doesn't choke because of bandwidth consumption, I would be interested in building a parallel client for your protocol to try sending and receiving pictures.Andrew, KA2DDOauthor of YAAC ("Yet Another APRS Client") -------- Original message -------- From: Scott Howard Date: 6/28/20 19:19 (GMT-05:00) To: aprssig at lists.tapr.org Subject: [aprssig] Packet Compressed Sensing Imaging (PCSI) Dear APRS SIG,I'm happy to share a new image transfer method called PCSI that?a team of students and I have been developing during quarantine. PCSI is digital (packet based), unconnected multicast (UI frames), compatible with APRS (basically turbo-charged APRS Vision?https://www.tapr.org/pdf/DCC1997-APRSvision-WB4APR.pdf), resilient?to packet loss (every receiving station can receive a different random set of packets and still reconstruct the entire image), and computationally trivial for the transmitter (8-bit microcontroller can easily construct packets). The goal is to be used with low-power microcontrollers and weak signals (even HF modes) transmitting images when packets will likely be lost. In SSTV and other unconnected digital image modes like SSDV, if the signal is weak or packets are lost, entire sections of the image are distorted or missing. In PCSI, if packets are lost, you still receive the entire image. Every additional packet received (in any order) simply increases image quality. Images take between 1-4 minutes to come in using 1200 baud, which is on par with SSTV. It's all controlled with an easy GUI where you just set your call sign, load your file, then click send.I've used it to transmit images locally between a hamshield KISS system and a kenwood TH-D72a, and between two direwolf systems acoustically through speakers and microphones. Now it's ready for testing in the wild.Details and usage videos are here:https://maqifrnswa.github.io/PCSI/?Windows and Linux binaries (for TCP or serial port KISS devices) are available here:https://github.com/maqifrnswa/PCSI/releases/tag/v0.0.0?(It should work on Macs too, I just don't have one to build binaries. If you're comfortable with python on Mac, you can also just use the source code.)Python Source code (everything is open source):https://github.com/maqifrnswa/PCSI?The method isn't necessarily tied to APRS and can be used over any band or mode, but if you'd like to explore its use for tactical and timely image transmission over APRS (basically the goal of APRS Vision), you can set it to use base91 encoding, use the "{{V" info prefix, and use an appropriate altnet. For now, I've been using the destination?address PCSI to indicate that these are PCSI packets.Since this is a specialized group of experts, I'd appreciate any testing and feedback you?can give. It's kind of a fun mode - you start watching the entire image come in over time, and as packets arrive, the image comes in to focus. To transmit and receive, you just need any KISS TNC/soundmodem/direwolf/etc. It might be a cool way to send low-res images over lossy and weak HF channels when you don't want to spend bits on FEC (although you could also put FEC on top of this method). Any feature requests, advice, or tips are welcome as well.Backstory: When CoVid-19 shut down universities, students weren't able to continue lab based work. I came up with this project so that undergraduate lab?assistants could work remotely while supporting a new educational initiative that my university is pursuing around students developing technology for high altitude balloons. The results are like magic - even receiving 20%-30% of the total bytes of the original image (i.e., 70-80% packet loss) gives high quality images. And it's a good introduction for students to the math behind compressed sensing imaging. There are also other tricks under the hood, like the optional use of chroma compression to increase speed.Cheers and thanks!Scott-- Scott Howard, PhDAssociate ProfessorDepartment of Electrical EngineeringUniversity of Notre Damehttp://ee.nd.edu574-631-2570 (direct)574-631-4393 (fax)https://howardphotonics.nd.eduFollow me on Twitter @HowardPhotonics262 Fitzpatrick HallNotre Dame, IN 46556 -------------- next part -------------- An HTML attachment was scrubbed... URL: From showard at nd.edu Tue Jun 30 10:42:17 2020 From: showard at nd.edu (Scott Howard) Date: Tue, 30 Jun 2020 10:42:17 -0400 Subject: [aprssig] Packet Compressed Sensing Imaging (PCSI) In-Reply-To: References: Message-ID: Hi Andrew, On Mon, Jun 29, 2020 at 11:55 PM spam8mybrain wrote: > > Interesting concept. What is the packet transmit rate with your protocol? Can it coexist with other users on the channel by waiting between packets, or will it saturate the channel until the picture is sent? You can set the packet rate to whatever you'd like in the software (packet order and loss doesn't matter, so super-slow is fine). If you have a dedicated channel, you can just spam away (like SSTV or SSDV does). If you're sharing a channel (like APRS), you obviously must be more considerate. The software is using your TNC's CSMA, so it should sense channel usage and not hog bandwidth. I was thinking of doing some kind of algorithm to adjust the persistence of the CSMA based on the number of simultaneous users in the future. Imagine there are a bunch of stations on a non-APRS frequency all sending their own images to each other simultaneously (an "image net"). The software already is set up to acquire all those images simultaneously, and you can switch back and forth between them as they come in. Each client knows how many other stations are present on the image net at the same time and can adjust persistence for optimal transmission rate and channel sharing. That's something impossible with SSTV, and something cool to do. You also can imagine having an event where you want images simultaneously from multiple locations, each with poor signals and low power. You can create your own image net and see all of them at the same time, regardless of fading or interference. If such an "image net" is timely, tactical, and appropriate to do over APRS, you can limit it to a specific digipeater so packets don't leak out of the local area. (That's why "digipeaters" is blank by default in the software. You should be smart and not just spam WIDE unless there's a specific reason to). I live in a rural area, so APRS traffic is very light (typically at <5% channel capacity). We've been testing PCSI by just bouncing off of a single specific APRS digipeater without affecting the network. That digipeater is also an igate, so we can check up on it on aprs.fi even if no one else is listening at that moment. When using PCSI with APRS, you can set your TNC's persistence to be very low. This should give "priority" to other traffic. You also can reduce image size. You may not need to send a 320x240 (SSTV resolution) image over APRS. You can even send messages similar to Hellschreiber. A 16x160 "image" that just contains text can be sent in 10 packets or so. Now that I think of it, if you send 1 bit color (B&W), you might actually be able to send the 16x160 "image" in a single APRS packet... I haven't thought of that yet, but that could be cool. We'd have to modify our packet specification a little bit to allow for black and white (or even grayscale) images. > Assuming the Father of APRS doesn't choke because of bandwidth consumption, I would be interested in building a parallel client for your protocol to try sending and receiving pictures. My "fear" of using PCSI with APRS is the irresponsible usage of bandwidth. There are good and bad use cases. Maybe a good use case is to extend the "Automatic Picture Relay Network" (http://www.aprs.org/aprn.html) to include PCSI "image nets." This way you just send the info to APRS that an image net is happening on a frequency, then people can switch over to that frequency to participate. Unlike SSTV as originally used in APRN, PCSI uses AX.25 frames just like APRS, so the exact same software (e.g., YAAC) can be used to participate in image nets as they do to manage APRS. You can also think about a national image net service similar to the UK's SSDV image aggregator (https://ssdv.habhub.org/) where everyone just uploads the packets they receive to some server that reconstructs them. In that case, individual clients don't even need to know how to decode the packets, they just relay them. This way balloons or other systems can send high quality images rapidly regardless of location and without necessarily needing digipeating or APRS. I'd be happy to help if anyone is interested in developing a different client. The tricky part is the math behind compressed sensing if you haven't seen it before, so we can help out with that. Maybe we can just make a C library that takes whatever has been received and spits out an image so anyone can incorporate it into software. Our next steps is to get the python CLI fully working so people can send/receive using a headless Raspberry Pi, and then it is to make an Arduino transmission client so people can put them on real low-power devices (e.g., hamshields on balloons). Cheers, Scott (KD9PDP) From mobilinkd at gmail.com Tue Jun 30 14:57:20 2020 From: mobilinkd at gmail.com (Mobilinkd LLC) Date: Tue, 30 Jun 2020 13:57:20 -0500 Subject: [aprssig] Packet Compressed Sensing Imaging (PCSI) In-Reply-To: References: Message-ID: Would love to see iOS and Android versions of this -- send/receive photos directly from a smart device. If there's anything I can do to help make this happen please let me know. I've linked to your work here: https://www.reddit.com/r/hamdevs/comments/hisp7h/packet_compressed_sensing_imaging_pcsi/ Kind Regards, Rob Riggs WX9O Mobilinkd LLC On Sun, Jun 28, 2020 at 6:20 PM Scott Howard wrote: > Dear APRS SIG, > > I'm happy to share a new image transfer method called PCSI that a team of > students and I have been developing during quarantine. PCSI is digital > (packet based), unconnected multicast (UI frames), compatible with APRS > (basically turbo-charged APRS Vision > https://www.tapr.org/pdf/DCC1997-APRSvision-WB4APR.pdf), resilient to > packet loss (every receiving station can receive a different random set of > packets and still reconstruct the entire image), and computationally > trivial for the transmitter (8-bit microcontroller can easily construct > packets). The goal is to be used with low-power microcontrollers and weak > signals (even HF modes) transmitting images when packets will likely be > lost. In SSTV and other unconnected digital image modes like SSDV, if the > signal is weak or packets are lost, entire sections of the image are > distorted or missing. In PCSI, if packets are lost, you still receive the > entire image. Every additional packet received (in any order) simply > increases image quality. Images take between 1-4 minutes to come in using > 1200 baud, which is on par with SSTV. It's all controlled with an easy GUI > where you just set your call sign, load your file, then click send. > > I've used it to transmit images locally between a hamshield KISS system > and a kenwood TH-D72a, and between two direwolf systems acoustically > through speakers and microphones. Now it's ready for testing in the wild. > *Details and usage videos are here:* > https://maqifrnswa.github.io/PCSI/ > *Windows and Linux binaries* (for TCP or serial port KISS devices) are > available here: > https://github.com/maqifrnswa/PCSI/releases/tag/v0.0.0 (It should work on > Macs too, I just don't have one to build binaries. If you're comfortable > with python on Mac, you can also just use the source code.) > *Python Source code (everything is open source)*: > https://github.com/maqifrnswa/PCSI > > The method isn't necessarily tied to APRS and can be used over any band or > mode, but if you'd like to explore its use for tactical and timely image > transmission over APRS (basically the goal of APRS Vision), you can set it > to use base91 encoding, use the "{{V" info prefix, and use an appropriate > altnet. For now, I've been using the destination address PCSI to indicate > that these are PCSI packets. > > Since this is a specialized group of experts, I'd appreciate any testing > and feedback you can give. It's kind of a fun mode - you start watching the > entire image come in over time, and as packets arrive, the image comes in > to focus. To transmit and receive, you just need any KISS > TNC/soundmodem/direwolf/etc. It might be a cool way to send low-res images > over lossy and weak HF channels when you don't want to spend bits on FEC > (although you could also put FEC on top of this method). Any feature > requests, advice, or tips are welcome as well. > > Backstory: When CoVid-19 shut down universities, students weren't able to > continue lab based work. I came up with this project so that undergraduate > lab assistants could work remotely while supporting a new educational > initiative that my university is pursuing around students developing > technology for high altitude balloons. The results are like magic - even > receiving 20%-30% of the total bytes of the original image (i.e., 70-80% > packet loss) gives high quality images. And it's a good introduction for > students to the math behind compressed sensing imaging. There are also > other tricks under the hood, like the optional use of chroma compression to > increase speed. > > Cheers and thanks! > Scott > > -- > > > *Scott Howard, PhD* > *Associate Professor* > Department of Electrical Engineering > University of Notre Dame > http://ee.nd.edu > > 574-631-2570 (direct) > 574-631-4393 (fax) > > h ttps://howardphotonics.nd.edu > Follow me on Twitter @HowardPhotonics > > > 262 Fitzpatrick Hall > Notre Dame, IN 46556 > > > _______________________________________________ > aprssig mailing list > aprssig at lists.tapr.org > http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From showard at nd.edu Tue Jun 30 17:10:32 2020 From: showard at nd.edu (Scott Howard) Date: Tue, 30 Jun 2020 17:10:32 -0400 Subject: [aprssig] Packet Compressed Sensing Imaging (PCSI) In-Reply-To: References: Message-ID: Hi Rob, On Tue, Jun 30, 2020 at 2:57 PM Mobilinkd LLC wrote: > Would love to see iOS and Android versions of this -- send/receive photos > directly from a smart device. If there's anything I can do to help make > this happen please let me know. > A mobile app would be awesome, especially combined with a mobilinkd tnc since you have the camera+processing power in the phone already. I don't know much about mobile app development, but I'm confident a mobile app can easily be made to transmit (it's just "find these specific pixel values, pack them into a packet, repeat"). Reconstructing received images is possible, I just don't know how fast liblbfgs runs on mobile processors ( https://github.com/chokkan/liblbfgs). Nonetheless, transmitting is trivial, you can always have a laptop connected to a station to decode images, and you can have each phone+tnc be a digipeater to relay distant camera images to the base station. This way even if a TNC doesn't have the computational power to reconstruct the image, it at least can relay it to something that can. We can talk off-list about what is needed for a mobile app, please let me know what you're thinking. There may even be some students that can help out. This is a good social distancing compatible project for undergrad EE/CS majors. -Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: