| |
ZL3AI > APRDIG 15.06.04 10:16l 273 Lines 10592 Bytes #999 (0) @ WW
BID : 3459-ZL3AI
Read: GUEST
Subj: TAPR Digest, Jun 08, 5/5
Path: DB0FHN<DB0FOR<DB0MRW<OK0PPL<DB0RES<ON0AR<7M3TJZ<EA5AKC<ZL2BAU<ZL2BAU<
ZL3VML
Sent: 040615/0712Z @:ZL3VML.#80.NZL.OC #:25879 [Chch-NZ] FBB7.00i $:3459-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: Tetroon collateral damage report, revision1
From: "Scott Miller" <scott@opentrac.org>
Date: Tue, 8 Jun 2004 16:23:02 -0700
X-Message-Number: 79
Hi Jason,
If PID filtering was indeed set and working properly, then chances are it
wasn't the OpenTRAC packets causing the problem. If you're willing to
experiment with it a bit, I could dig up some of the raw APRS packets that
were sent by the balloon and we can see if there's something there it was
choking on. They were pretty long, with timestamp, course/speed, altitude,
voltage, temperature, and an email address - it's entirely possible the
HamHUD had a problem with something in all that mess.
If you've got any non-PID 0xF0 traffic in your area, you might try having
the TNC listen to that for awhile and monitor the converse mode output to
see if the filtering is actually working right.
Or, if you'd like, I can loan you an OpenTracker and we can try to duplicate
the problem that way.
Scott
N1VG
----- Original Message -----
From: "Jason Rausch" <ke4nyv@hamhud.net>
To: "TAPR APRS Special Interest Group" <aprssig@lists.tapr.org>
Sent: Tuesday, June 08, 2004 5:33 PM
Subject: [aprssig] Re: Tetroon collateral damage report, revision1
>>...is that a HamHud user had problems because their TNC was not configured
>>to reject PID=0x70 packets.
>
>Sorry Greg or whoever (I lost track a long damn time ago), but that is
>INCORRECT. I AM the HamHUD user being spoke of in many of these posts.
>There has been extensive discussion about this on the HumHUD SIG and one of
>the first requests made to me was to check MY TNC for the PID check. I
>confirmed that was NOT the problem. So it was NOT a matter of MY TNC being
>configured properly.
>
>I just wanted to set the record straight that I was not making a complaint
>based on MY neglagence. The packets were indeed somthing irregular. There
>was somthing in them that did not want to play nice with the HH2 parser.
>That...is being worked on.
>
>Jason KE4NYV
>www.ke4nyv.com
>RPC Elecronics
>www.ke4nyv.com/rpc
----------------------------------------------------------------------
Subject: RE: tapr email server is being blacklisted
From: "Eric H. Christensen" <kf4otn@earthlink.net>
Date: Tue, 8 Jun 2004 19:35:32 -0400
X-Message-Number: 80
Hmmm.... That might explain why I wasn't getting my messages via my ECU
account... I switched it over to my Earthlink account and no problems!
73s,
Eric KF4OTN
kf4otn@amsat.org
----------------------------------------------------------------------
Subject: APRS Hardware
From: "deni" <deni@dwatt.com>
Date: Tue, 8 Jun 2004 20:39:04 -0500
X-Message-Number: 81
Gentlemen,
I have been told this is the place to get recommendations for hardware. I
want something that I can put into my vehicle and then not have to bother
with it anymore. If I could get it all in one packet that would be better
but I do not seem to find anything like that. The tiny track III looks like
a good start. At the moment, I have nothing (mobile that is) and am anxious
to get reporting my whereabouts while mobile.
Any ideas and suggestions appreciated, either on or off the list.
Thanks and 73
Deni
WB0TAX
----------------------------------------------------------------------
Subject: Re: Tetroon collateral damage report, revision1
From: Jeff King <jeff@aerodata.net>
Date: Tue, 8 Jun 2004 21:54:40 -0400
X-Message-Number: 82
On Tue, 8 Jun 2004 16:15:00 -0700, Scott Miller wrote:
>>4. Frequency agile radios. Use 144.39 down low for initial
>>assent/descent and
>>recovery, but QSY to another frequency, like 144.34, when at
>>altitude... doable with Pocket Tracker
>Speaking of which, I've been thinking about doing this with the
>OpenTracker - add frequency as an option in the config profiles, and
>use an output pin to control the Pocket Tracker. Of course,
>integrating a Pocket Tracker with an OpenTracker requires a band saw
>and some soldering. =]
I'd use a Dremal myself to cut the traces. I looked at this already, like I
said, should be doable. You toss out the 12F pic, and multiplex one of the
SOTT pins to control the SPI input of the PLL part.
Not optimal, but a good first proof of concept. I imagine you could even drop
one of your MOT parts on the board, with some serious trace cutting. 18 PIN
DIP socket
----------------------------------------------------------------------
Subject: Re: Tetroon collateral damage report, revision1
From: "Gregg G. Wonderly" <gregg@skymaster.cytetech.com>
Date: Tue, 08 Jun 2004 21:08:06 -0500
X-Message-Number: 83
>>...is that a HamHud user had problems because their TNC was not configured
>>to reject PID=0x70 packets.
>
>Sorry Greg or whoever (I lost track a long d*** time ago), but that is
>INCORRECT. I AM the HamHUD user being spoke of in many of these posts.
>There has been extensive discussion about this on the HumHUD SIG and one of
>the first requests made to me was to check MY TNC for the PID check. I
>confirmed that was NOT the problem. So it was NOT a matter of MY TNC being
>configured properly.
Okay, great, then the OpenTrac packet should not have made it into the HamHUD
then, so it must of been the complex APRS packet that was the issue. It would
be great to take that packet and hand walk though the code to see what went
wrong!
-----
gregg@cytetech.com (Cyte Technologies Inc)
----------------------------------------------------------------------
Subject: Re: APRS Protocol - A Modest Proposal
From: "Gregg G. Wonderly" <gregg@skymaster.cytetech.com>
Date: Tue, 08 Jun 2004 21:09:12 -0500
X-Message-Number: 84
>I am fully aware of how TCP/IP works and what can be transported across
>it. My statement still stands. Due to the architecture of the APRS-IS
>interconnect protocol and the architecture of the APRS-IS servers,
>IGates, and clients, APRS-IS does not and will not support a binary
>protocol.
....
>As I also stated, we are investigating creating a more universal
>transport protocol that would allow transport of not only AX.25 packets
>of any flavor but also data from some other amateur radio disciplines,
>as well.
Well, this was exactly what I was saying should be done. I guess that I just
didn't use the right words to help you see that.
-----
gregg@cytetech.com (Cyte Technologies Inc)
----------------------------------------------------------------------
Subject: Re: Tetroon collateral damage report, revision1
From: "Jason Rausch" <ke4nyv@hamhud.net>
Date: Tue, 8 Jun 2004 21:29:10
X-Message-Number: 85
>Okay, great, then the OpenTrac packet should not have made it into the
>HamHUD then, so it must of been the complex APRS packet that was the
>issue.
Thats what I have just about concluded. I think the packet that had all of
the telemetry data is what caused the HH2's parser to choke. The HUD can
parse any regular packet written out in the spec. Any packet it does not
understand is displayed in a "raw data" display. My guess is, the "raw
data" was too long and caused the choke. Every lockup would have the
balloons callsign currently displayed. That tells me the packet was at
least parsable up to the call and path, then all went to hell after that.
>It would be great to take that packet and hand walk though the code to see
>what went wrong!
I think Scott is going to lend either me or Dale a loaner OpenTrac board to
generate actual on-air packets to test with and possibly snuff out the
problem.
Jason KE4NYV
www.ke4nyv.com
RPC Electronics
www.ke4nyv.com/rpc
----------------------------------------------------------------------
Subject: Re: APRS Protocol - A Modest Proposal
From: "AE5PL Lists" <HamLists@ametx.com>
Date: Tue, 8 Jun 2004 21:59:26 -0500
X-Message-Number: 86
Gregg, I stated this in my first post in this thread in much simpler
language. And this predates any conversation you have had with me by
email. So you didn't help me see that, Henk didn't help me see that,
and you apparently didn't comprehend my previous posts. And this isn't
what you said should be done. You stated that the current APRS-IS
architecture be changed. My statements are quite contrary to that.
Reread my posts before taking credit for something you or anyone else on
this thread didn't do.
I apologize to the SIG for the tone of this post, but don't take credit
where it isn't due.
73,
Pete Loveall AE5PL
mailto:pete@ae5pl.net
>-----Original Message-----
>From: Gregg G. Wonderly
>
>Well, this was exactly what I was saying should be done. I
>guess that I just didn't use the right words to help you see that.
----------------------------------------------------------------------
Subject: Re: D700 - Yes mine has FLASH and In-Circuit Programming.
From: John Hall <n5jrh@houstonhams.org>
Date: Tue, 08 Jun 2004 22:04:07 -0500
X-Message-Number: 87
Only problem with NEC microcontrollers, flash or otherwise, does not allow
reading of the devices through their programming algorithms. They only
allow verification by sending the pattern that is expected to be in the
devices memory. They are not the easiest to program but the NEC Flashpro
III or 4 can handle ICP easily.
John - N5JRH
At 03:02 PM 6/8/2004, you wrote:
>Not only does it have flash, but it has the proper connection (a flat 10
>pin ribbon would attach to the NEC Programmer interface) to actually
>program it in-circuit. It's clear their intentions were to be able to
>update the software if the need came up. Noone'd put an ICP compatible
>plug there for, no reason.
>
>I used a multitester and documented all the pins instead of sleeping
>because I was so baffled by this.
>
>Anyone else who has a D700 is encouraged to pull it apart and see if you
>see what I do.. Maybe there are some that use a Masked ROM. I'm sure it
>still probably has the same programming connection and probably the Non-F
>model of the same chip, or a compatible one, if that's the case.
>
>I'd be interested to know who made the firmware for them.. I was VERY
>bummed to find out it doesn't have an easy in-system flash
>though. Otherwise I would've dumped the chip this morning too.
>
>The Tasco TNC board also has a flash memory.. I forget the part number but
>it likely has the firmware in it. Tasco is long gone (by the looks of
>it), although I think maybe they sold their FSK Modem designs to TI.. Not
>100% sure though. Could probably use any TNC Modem. The thing is on a
>daughterboard.
>
>Not sure how the D7A and A(G)'s are done since I don't own one to rip apart.
>
>--Droo, K1XVM
---
END OF DIGEST
Read previous mail | Read next mail
| |
