| |
ZL3AI > APRDIG 10.05.04 20:18l 241 Lines 9156 Bytes #999 (0) @ WW
BID : 3197-ZL3AI
Read: GUEST
Subj: TAPR Digest, Apr 21, 1/10
Path: DB0FHN<DB0RGB<OK0PPL<DB0RES<ON0AR<WB0TAX<VK7AX<VK4TTT<ZL2BAU<ZL3VML
Sent: 040510/1814Z @:ZL3VML.#80.NZL.OC #:23727 [Chch-NZ] FBB7.00i $:3197-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
TAPR APRS Special Interest Group Digest for Wednesday, April 21, 2004.
1. Re: APRS Kenwood Radios
2. Re: APRS Kenwood Radios
3. RE: Reprogramming the D700
4. Re: APRS greater precision
5. APRS-a Newbie's Perspective
6. UI-View Questions
7. RE: UI-View Questions
8. Re: APRS Kenwood Radios
9. Re: [ui-view] Ambiguity?
10. RE: Reprogramming the D700
11. RE: Reprogramming the D700
12. Re: APRS greater precision
13. Re: APRS Kenwood Radios
14. Kenwood radios [was Re: APRS greater precision]
15. Re: Kenwood MObile APRS
16. Re: APRS greater precision
17. Re: APRS Kenwood Radios
18. Re: Kenwood radios [was Re: APRS greater precision]
19. Re: Kenwood MObile APRS
20. Re: Kenwood radios [was Re: APRS greater precision
21. Kenwood radios [was Re: APRS greater precision
22. Re: APRS-a Newbie's Perspective
23. Re: APRS greater precision
24. Re: APRS greater precision
25. Re: APRS greater precision
26. Re: UI-View Questions
27. Re: APRS greater precision
28. Re: [ui-view] Ambiguity?
29. Re: [ui-view] Ambiguity?
30. Re: APRS Kenwood Radios
31. Re: Kenwood MObile APRS
32. Re: [ui-view] Ambiguity?
33. Re: Kenwood MObile APRS
<LYR36507-195569-2004.04.21-18.00.55--mikejp#videotron.ca@lists.tapr.org>
34. Drawing Ambiguity circles...
35. Re: [ui-view] Ambiguity?
36. Re: [ui-view] Ambiguity?
37. Introduction
38. Re: Introduction
39. Re: [ui-view] Ambiguity?
40. Re: [ui-view] Ambiguity?
41. Re: [ui-view] Ambiguity?
42. NOAA Environmal Hero Awards to two CWOP hams
43. Additional thoughts on the great debate....
44. Re: Additional thoughts on the great debate....
45. Re: Additional thoughts on the great debate....
46. Re: Additional thoughts on the great debate....
47. Re: Introduction
48. Re: APRS greater precision
49. Re: Additional thoughts on the great debate....
50. Re: APRS greater precision
51. got it!
----------------------------------------------------------------------
Subject: Re: APRS Kenwood Radios
From: "Scott Miller" <scott@3xf.com>
Date: Tue, 20 Apr 2004 21:54:58 -0700
X-Message-Number: 1
>As far as the firmware upgrades go, I don't think it would be legal to make
>ham radios with upgradable firmware since someone would then figure out how
>to circumvent the FCC rules like no receive in the cell phone bands and
That's easy to fix. Use a separate processor with non-upgradeable (or at
least secured) firmware that handles all of the back-end RF stuff. Use a
CAN or similar inter-processor bus to connect it to the front end processor.
Cost isn't a big deal - these aren't Pentium IV's we're talking about. An
appropriate processor would probably be in the $3 to $12 range, and the
architecture gives you other advantages like keeping all of the
timing-critical stuff separate from the user interface.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: APRS Kenwood Radios
From: David VanHorn <dvanhorn@cedar.net>
Date: Wed, 21 Apr 2004 00:08:53 -0500
X-Message-Number: 2
At 09:54 PM 4/20/2004 -0700, Scott Miller wrote:
>>As far as the firmware upgrades go, I don't think it would be legal to make
>>ham radios with upgradable firmware since someone would then figure out how
>>to circumvent the FCC rules like no receive in the cell phone bands and
>
>That's easy to fix. Use a separate processor with non-upgradeable (or at
>least secured) firmware that handles all of the back-end RF stuff. Use a
>CAN or similar inter-processor bus to connect it to the front end processor.
>Cost isn't a big deal - these aren't Pentium IV's we're talking about. An
>appropriate processor would probably be in the $3 to $12 range, and the
>architecture gives you other advantages like keeping all of the
>timing-critical stuff separate from the user interface.
Exactly.
My printer does the same thing. The printhead processor, which can actually
cause a fire if it crashes or is done wrong, is separate from the
communication processor, which we will let our customers have the code for.
The battery charger processor is also separate, same reason.
If you told it to receive or transmit somewhere it isn't allowed to, then
it would either return an error, or just do nothing with the command.
----------------------------------------------------------------------
Subject: RE: Reprogramming the D700
From: "Scott Miller" <scott@3xf.com>
Date: Tue, 20 Apr 2004 22:15:57 -0700
X-Message-Number: 3
>Something is just nagging me... There has to be a way to go into the D700,
>physically remove the firmware, read the firmware, fix the problems on the
>computer, and then burn a new chip and put it back in...
Without having seen the innards of a D700, let me answer this in generic
terms. The firmware could be in memory internal to the processor, protected
from outside access. You see this a lot in smaller chips especially - the
TinyTrak, for example, won't let you at the firmware, assuming Byon's got
the protection set up properly. Yeah, it's possible to get at it still, but
it'd probably involve hot fuming nitric acid, microscopic examination of the
de-lidded part, and some knowledge of the die layout.
I don't think that's the case for the D700. So assuming it's in an external
chip, you should be able to extract the code. Now your problem is that what
you've extracted is machine code - raw processor instructions and their
operands. It can be disassembled, but if you've never dealt with assembly
language it's difficult to convey how hard it can be to make sense of a
complex program at this level, devoid of any labels or comments. A quick
example:
(address, raw data, disassembled code)
0010 ae00 LDX c012
0012 8c CLRH
0013 cd0000 JSR fe62
0016 40000000 DC.L 1073741824
001a 95 TSX
001b e603 LDA 3,X
001d 87 PSHA
001e e602 LDA 2,X
0020 87 PSHA
0021 e601 LDA 1,X
0023 87 PSHA
0024 f6 LDA ,X
0025 87 PSHA
0026 5f CLRX
0027 a616 LDA c015
0029 cd0000 JSR fe9a
002c a704 AIS #4
This is a snipped of OpenTracker code, with the labels replaced with (bogus)
hex addresses as you'd see it from the raw code. You have no easy way to
determine that the code started out as:
base91(1073741824L - fixdata.latitude, fixdata.aprs_position);
Ok, so that still might be really clear, but some examination of the source
code tells you that base91() is a function that takes a number and converts
it to base91 compressed format and stores it in a specified spot.
Without the source code, it's a very labor intensive task to reverse
engineer the firmware. You don't even come close to starting on an equal
footing with the original programmers.
That's not to say it can't be done. Many years ago I used to use an object
level debugger to make patches and cheats for games and things on the PC.
That usually just involved changing a compare instruction or two, but
finding the right instruction could take hours of tedious examination and
tracing.
So it's possible, yes, but not practical. Not unless Kenwood wants to hand
over their source code. And that's the whole point behind the Open Source
movement, is that the source code is available to anyone - you can see how
it's built, and you can change it to suit your needs. I just don't expect
to see commercial radio manufacturers embracing this model any time soon.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: APRS greater precision
From: Gerry Creager N5JXS <gerry.creager@tamu.edu>
Date: Wed, 21 Apr 2004 02:26:57 -0500
X-Message-Number: 4
<Sigh!>
We've been through that all before. George Washington and Thomas Jefferson
decreed the Prime Meridian for the United States would pass through
Washington DC. The Capitol Dome was supposed to be the anchor and
reference point.
The Brits think it belongs in Greenwich. The French think it belongs in
Paris.
The Russians felt Moscow or Petersburg had promise.
Then we sorta standardized on a worldwide system. Which certainly makes
teaching this stuff a lot easier!
gerry
Curt, WE7U wrote:
>On Mon, 19 Apr 2004, Scott Miller wrote:
>
>>Next time, we need to make sure we get a spherical planet. This irregular
>>oblate spheroid thing just isn't cutting it.
>
>Yea, but then people would argue over where the prime meridian is...
>
>--
>Curt, WE7U archer at eskimo dot com
>Arlington, WA, USA http://www.eskimo.com/~archer
>"Lotto: A tax on people who are bad at math." -- unknown
>"Windows: Microsoft's tax on computer illiterates." -- WE7U
>"The world DOES revolve around me: I picked the coordinate system!"
--
Gerry Creager -- gerry.creager@tamu.edu
Network Engineering -- AATLT, Texas A&M University
Cell: 979.229.5301 Office: 979.458.4020 FAX: 979.847.8578
Page: 979.228.0173
Office: 903A Eller Bldg, TAMU, College Station, TX 77843
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
