From stanzepa at sbcglobal.net  Sat Feb 23 16:31:35 2008
From: stanzepa at sbcglobal.net (Stan Horzepa)
Date: Sat, 23 Feb 2008 11:31:35 -0500
Subject: [htaprs] Dayton Hamvention APRS Forum
Message-ID: <47C04A67.3010906@sbcglobal.net>

The APRS Forum at the Dayton Hamvention will be on Friday, May 16 at 
1315-1415 local time

If you are interested in speaking at the forum, please e-mail me ASAP 
with your name, call sign, and the specific topic you would like to 
speak about at the forum.

We only have an hour to cram everything in this year, so e-mail me ASAP 
to reserve a spot.

73,

Stan, WA1LOU
Hamvention APRS forum moderator



From scott at opentrac.org  Tue Feb 26 17:58:02 2008
From: scott at opentrac.org (Scott Miller)
Date: Tue, 26 Feb 2008 09:58:02 -0800
Subject: [htaprs] VC-H1
Message-ID: <47C4532A.2080902@opentrac.org>

Is this list still active?  I can't find any archives.  And is 
discussion of the VC-H1 still on-topic?

Scott
N1VG




From commsupport at aol.com  Tue Feb 26 18:02:28 2008
From: commsupport at aol.com (commsupport at aol.com)
Date: Tue, 26 Feb 2008 13:02:28 -0500
Subject: [htaprs] VC-H1
In-Reply-To: <47C4532A.2080902@opentrac.org>
References: <47C4532A.2080902@opentrac.org>
Message-ID: <8CA46B8E25725DF-FD0-1176@webmail-nf04.sim.aol.com>


 Some still lurking.? :)


 


 

-----Original Message-----
From: Scott Miller <scott at opentrac.org>
To: htaprs at lists.tapr.org
Sent: Tue, 26 Feb 2008 9:58 am
Subject: [htaprs] VC-H1









Is this list still active?  I can't find any archives.  And is 
discussion of the VC-H1 still on-topic??
?

Scott?

N1VG?
?


_______________________________________________?

htaprs mailing list?

htaprs at lists.tapr.org?

https://lists.tapr.org/cgi-bin/mailman/listinfo/htaprs?



 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.tapr.org/pipermail/htaprs/attachments/20080226/520a21df/attachment.htm 

From kd4moj at kd4moj.org  Tue Feb 26 18:37:27 2008
From: kd4moj at kd4moj.org (Doug Ferrell)
Date: Tue, 26 Feb 2008 13:37:27 -0500 (EST)
Subject: [htaprs] VC-H1
In-Reply-To: <47C4532A.2080902@opentrac.org>
Message-ID: <Pine.LNX.4.21.0802261337001.4723-100000@www.ferrellsecurity.com>

On Tue, 26 Feb 2008, Scott Miller wrote:

> Is this list still active?  I can't find any archives.  And is 
> discussion of the VC-H1 still on-topic?
> 
> Scott
> N1VG

 It's ALIVE!!!!!!!!!!!!!! We've created a monster!

-- 
...DOUG
KD4MOJ







From VA7OTC at rac.ca  Tue Feb 26 18:47:21 2008
From: VA7OTC at rac.ca (VA7OTC JD Erskine)
Date: Tue, 26 Feb 2008 10:47:21 -0800
Subject: [htaprs] VC-H1
In-Reply-To: <47C4532A.2080902@opentrac.org>
References: <47C4532A.2080902@opentrac.org>
Message-ID: <47C45EB9.1030009@rac.ca>

Scott Miller wrote:
> Is this list still active?  I can't find any archives.  And is 
> discussion of the VC-H1 still on-topic?
> 
> Scott
> N1VG

Appears to  be. I tried a search for VC-H1 on the TAPR site and didn't 
find much.

73 John/'JD'
VA7OTC VE0JD/mm

---


     * To: "TAPR AO-16 APRS Special Interest Group" 
<ao16aprs at lists.tapr.org>
     * Subject: [ao16aprs] HTAPRS expanded for VC H1
     * From: "Horzepa, Stan" <Stan_Horzepa at adc.com>
     * Date: Mon, 15 Feb 1999 14:38:30 -0600
     * List-Owner: <mailto:owner-ao16aprs at lists.tapr.org>
     * List-Software: Lyris Server version 3.0
     * List-Subscribe: <mailto:subscribe-ao16aprs at lists.tapr.org>
     * List-Unsubscribe: <mailto:leave-ao16aprs-833L at lists.tapr.org>

The purpose of the TAPR HTAPRS SIG has been expanded to include 
discussion of Kenwood's VC H1 (KenCam) and related issues, such as the 
Automatic Picture Relay Network (APRN). So, talk among yourselves about 
VC H1 on HTAPRS.

Stan, WA1LOU, *SIG administrator



From bruninga at usna.edu  Tue Feb 26 19:47:46 2008
From: bruninga at usna.edu (Robert Bruninga)
Date: Tue, 26 Feb 2008 14:47:46 -0500
Subject: [htaprs] VC-H1
In-Reply-To: <47C45EB9.1030009@rac.ca>
References: <47C4532A.2080902@opentrac.org> <47C45EB9.1030009@rac.ca>
Message-ID: <014801c878b0$75e24740$42577a83@ewlab.usna.edu>

> > Is this list still active?  
> > I can't find any archives.  And is 
> > discussion of the VC-H1 still on-topic?

I have several VC-H1's and rather than keeping them on the
shelves gathering dust, I now try to take them along with plenty
of D7's to most local ham radio support events.

Even have one on a quick-mount plate for adding to the county's
emergency operations comm truck for instant feed of video to all
their intrnal monitors.

Bob, Wb4APR




From scott at opentrac.org  Tue Feb 26 19:33:21 2008
From: scott at opentrac.org (Scott Miller)
Date: Tue, 26 Feb 2008 11:33:21 -0800
Subject: [htaprs] VC-H1
In-Reply-To: <47C45EB9.1030009@rac.ca>
References: <47C4532A.2080902@opentrac.org> <47C45EB9.1030009@rac.ca>
Message-ID: <47C46981.4030507@opentrac.org>

Well, seeing as I can't find any other VC-H1 group, or even any active 
SSTV group aside from MM-SSTV, I guess I'll ask this here.

My new project is up and running - it's a standalone SSTV encoder with 
camera.  Sort of like a transmit-only VC-H1, but it'll have more 
automation and remote control features.  It's also got a character 
generator that'll display 40 characters of text in the top 16 lines, and 
I may add a parser for GPS data and I'll definitely allow arbitrary text 
to be entered through a serial port for telemetry and such.

I'm not thrilled with the camera module, but it was reasonably easy to 
interface.  If I'm going to stick with this camera, the big question is 
which lens to use.  There's at least some possibility to allow the user 
to select a lens, but the mechanical design will limit the lens choice.

I'm currently using a 109 degree wide-angle lens.  It captures a lot of 
the scene, but it's hard to get much detail unless you're really close, 
and that introduces focus problems.  Anyone have any suggestions on what 
would be an appropriate FOV?

Also, any other deficiencies in the VC-H1 that I should try to avoid 
duplicating?

If I can get the transmitter to survive the high duty cycle, I'm going 
to try pairing one of my prototypes with an MX146 transmitter and see 
how small and light I can make a SSTV-capable high-altitude balloon payload.

I'll at least have a demo running at Dayton, and maybe even the first 
batch of production units, but I'm not making any promises yet.

Scott
N1VG

VA7OTC JD Erskine wrote:
> Scott Miller wrote:
>> Is this list still active?  I can't find any archives.  And is 
>> discussion of the VC-H1 still on-topic?
>>
>> Scott
>> N1VG
> 
> Appears to  be. I tried a search for VC-H1 on the TAPR site and didn't 
> find much.
> 
> 73 John/'JD'
> VA7OTC VE0JD/mm
> 
> ---
> 
> 
>     * To: "TAPR AO-16 APRS Special Interest Group" 
> <ao16aprs at lists.tapr.org>
>     * Subject: [ao16aprs] HTAPRS expanded for VC H1
>     * From: "Horzepa, Stan" <Stan_Horzepa at adc.com>
>     * Date: Mon, 15 Feb 1999 14:38:30 -0600
>     * List-Owner: <mailto:owner-ao16aprs at lists.tapr.org>
>     * List-Software: Lyris Server version 3.0
>     * List-Subscribe: <mailto:subscribe-ao16aprs at lists.tapr.org>
>     * List-Unsubscribe: <mailto:leave-ao16aprs-833L at lists.tapr.org>
> 
> The purpose of the TAPR HTAPRS SIG has been expanded to include 
> discussion of Kenwood's VC H1 (KenCam) and related issues, such as the 
> Automatic Picture Relay Network (APRN). So, talk among yourselves about 
> VC H1 on HTAPRS.
> 
> Stan, WA1LOU, *SIG administrator
> 
> _______________________________________________
> htaprs mailing list
> htaprs at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/htaprs
> 
> 




From scott at opentrac.org  Tue Feb 26 20:20:47 2008
From: scott at opentrac.org (Scott Miller)
Date: Tue, 26 Feb 2008 12:20:47 -0800
Subject: [htaprs] VC-H1
In-Reply-To: <014801c878b0$75e24740$42577a83@ewlab.usna.edu>
References: <47C4532A.2080902@opentrac.org> <47C45EB9.1030009@rac.ca>
	<014801c878b0$75e24740$42577a83@ewlab.usna.edu>
Message-ID: <47C4749F.7010405@opentrac.org>

Did anything ever happen with the APRN idea?  It wouldn't be too hard to 
add APRS capability to this thing - the processor is in the same family 
as the one in the OpenTracker+ (and the Tracker2) and much of the code 
could be ported straight over.

Scott
N1VG

Robert Bruninga wrote:
>> > Is this list still active?  
>> > I can't find any archives.  And is 
>> > discussion of the VC-H1 still on-topic?
> 
> I have several VC-H1's and rather than keeping them on the
> shelves gathering dust, I now try to take them along with plenty
> of D7's to most local ham radio support events.
> 
> Even have one on a quick-mount plate for adding to the county's
> emergency operations comm truck for instant feed of video to all
> their intrnal monitors.
> 
> Bob, Wb4APR
> 
> 
> _______________________________________________
> htaprs mailing list
> htaprs at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/htaprs
> 
> 




From n7yge at hctc.com  Tue Feb 26 20:46:45 2008
From: n7yge at hctc.com (Jerry N7YGE)
Date: Tue, 26 Feb 2008 12:46:45 -0800
Subject: [htaprs] VC-H1
In-Reply-To: <47C46981.4030507@opentrac.org>
Message-ID: <005b01c878b8$b3ae0160$6807a8c0@JERRY>

I have used this company for my fast scan ATV work for years.  
http://www.supercircuits.com/index.asp

They have an excellent assortment of cameras.  You might want to contact
them as to your specific needs.

If you are building a new black box, you might think about making it with
RCA jacks so you can change out the camera easily.  You might want a Infa
Red (IR) camera at times for night work.

Sounds like a fun project you have going.

Jerry N7YGE


-----Original Message-----
From: htaprs-bounces at lists.tapr.org [mailto:htaprs-bounces at lists.tapr.org]
On Behalf Of Scott Miller
Sent: Tuesday, February 26, 2008 11:33 AM
To: TAPR APRS Hot Topics Mailing List
Subject: Re: [htaprs] VC-H1


Well, seeing as I can't find any other VC-H1 group, or even any active 
SSTV group aside from MM-SSTV, I guess I'll ask this here.

My new project is up and running - it's a standalone SSTV encoder with 
camera.  Sort of like a transmit-only VC-H1, but it'll have more 
automation and remote control features.  It's also got a character 
generator that'll display 40 characters of text in the top 16 lines, and 
I may add a parser for GPS data and I'll definitely allow arbitrary text 
to be entered through a serial port for telemetry and such.

I'm not thrilled with the camera module, but it was reasonably easy to 
interface.  If I'm going to stick with this camera, the big question is 
which lens to use.  There's at least some possibility to allow the user 
to select a lens, but the mechanical design will limit the lens choice.

I'm currently using a 109 degree wide-angle lens.  It captures a lot of 
the scene, but it's hard to get much detail unless you're really close, 
and that introduces focus problems.  Anyone have any suggestions on what 
would be an appropriate FOV?

Also, any other deficiencies in the VC-H1 that I should try to avoid 
duplicating?

If I can get the transmitter to survive the high duty cycle, I'm going 
to try pairing one of my prototypes with an MX146 transmitter and see 
how small and light I can make a SSTV-capable high-altitude balloon payload.

I'll at least have a demo running at Dayton, and maybe even the first 
batch of production units, but I'm not making any promises yet.

Scott
N1VG

VA7OTC JD Erskine wrote:
> Scott Miller wrote:
>> Is this list still active?  I can't find any archives.  And is
>> discussion of the VC-H1 still on-topic?
>>
>> Scott
>> N1VG
> 
> Appears to  be. I tried a search for VC-H1 on the TAPR site and didn't
> find much.
> 
> 73 John/'JD'
> VA7OTC VE0JD/mm
> 
> ---
> 
> 
>     * To: "TAPR AO-16 APRS Special Interest Group"
> <ao16aprs at lists.tapr.org>
>     * Subject: [ao16aprs] HTAPRS expanded for VC H1
>     * From: "Horzepa, Stan" <Stan_Horzepa at adc.com>
>     * Date: Mon, 15 Feb 1999 14:38:30 -0600
>     * List-Owner: <mailto:owner-ao16aprs at lists.tapr.org>
>     * List-Software: Lyris Server version 3.0
>     * List-Subscribe: <mailto:subscribe-ao16aprs at lists.tapr.org>
>     * List-Unsubscribe: <mailto:leave-ao16aprs-833L at lists.tapr.org>
> 
> The purpose of the TAPR HTAPRS SIG has been expanded to include
> discussion of Kenwood's VC H1 (KenCam) and related issues, such as the 
> Automatic Picture Relay Network (APRN). So, talk among yourselves about 
> VC H1 on HTAPRS.
> 
> Stan, WA1LOU, *SIG administrator
> 
> _______________________________________________
> htaprs mailing list
> htaprs at lists.tapr.org 
> https://lists.tapr.org/cgi-bin/mailman/listinfo/htaprs
> 
> 


_______________________________________________
htaprs mailing list
htaprs at lists.tapr.org https://lists.tapr.org/cgi-bin/mailman/listinfo/htaprs





From bruninga at usna.edu  Tue Feb 26 22:46:05 2008
From: bruninga at usna.edu (Robert Bruninga)
Date: Tue, 26 Feb 2008 17:46:05 -0500
Subject: [htaprs] VC-H1
In-Reply-To: <47C4749F.7010405@opentrac.org>
References: <47C4532A.2080902@opentrac.org> <47C45EB9.1030009@rac.ca>
	<014801c878b0$75e24740$42577a83@ewlab.usna.edu>
	<47C4749F.7010405@opentrac.org>
Message-ID: <01ed01c878c9$5f2c2f70$42577a83@ewlab.usna.edu>

> Did anything ever happen with the APRN idea?  

Not that I remember.  There was one individual that had
something working, but I 'm not sure I can find the link.  The
concept was great if we are going to use SSTV, and that is that
APRS provided the ability to LABEL the pictures, and assign them
a POSITION...

> It wouldn't be too hard to add APRS capability 
> to this thing - the processor is in the 
> same family as the one in the OpenTracker+ 
> (and the Tracker2) and much of 
> the code could be ported straight over.

Not sure how many people still have them.  And not being in
production is a sever limitation to future apps.  However, there
are LOTS of SSTV packages for laptops with sound cards... Maybe
there is wehre the application should really apply.  Then you
don't need a processor, since the same PC can geenerate the APRS
tones as well as the SSTV tones.

Maybe we just need to lean on the SSTV code authors to add APRS
labels an dposits to each picture?

Bob

> 
> Scott
> N1VG
> 
> Robert Bruninga wrote:
> >> > Is this list still active?  
> >> > I can't find any archives.  And is 
> >> > discussion of the VC-H1 still on-topic?
> > 
> > I have several VC-H1's and rather than keeping them on the
> > shelves gathering dust, I now try to take them along with
plenty
> > of D7's to most local ham radio support events.
> > 
> > Even have one on a quick-mount plate for adding to the
county's
> > emergency operations comm truck for instant feed of video to
all
> > their intrnal monitors.
> > 
> > Bob, Wb4APR
> > 
> > 
> > _______________________________________________
> > htaprs mailing list
> > htaprs at lists.tapr.org
> > https://lists.tapr.org/cgi-bin/mailman/listinfo/htaprs
> > 
> > 
> 
> 




From bruninga at usna.edu  Tue Feb 26 22:48:29 2008
From: bruninga at usna.edu (Robert Bruninga)
Date: Tue, 26 Feb 2008 17:48:29 -0500
Subject: [htaprs] VC-H1
In-Reply-To: <47C46981.4030507@opentrac.org>
References: <47C4532A.2080902@opentrac.org> <47C45EB9.1030009@rac.ca>
	<47C46981.4030507@opentrac.org>
Message-ID: <01ee01c878c9$b5028520$42577a83@ewlab.usna.edu>

Wow, Im reading email in reverse order.

Yes, by all means.  If you can get a VCH-1 look-alike on the
air, then by all means lets make sure it transmits its APRS
position and status packets on the tail end.

Then we can link these to LIVE web pages, and really make some
progress on APRN!

Bob, WB4APR
 

> -----Original Message-----
> From: htaprs-bounces at lists.tapr.org 
> [mailto:htaprs-bounces at lists.tapr.org] On Behalf Of Scott
Miller
> Sent: Tuesday, February 26, 2008 2:33 PM
> To: TAPR APRS Hot Topics Mailing List
> Subject: Re: [htaprs] VC-H1
> 
> Well, seeing as I can't find any other VC-H1 group, or even 
> any active 
> SSTV group aside from MM-SSTV, I guess I'll ask this here.
> 
> My new project is up and running - it's a standalone SSTV 
> encoder with 
> camera.  Sort of like a transmit-only VC-H1, but it'll have
more 
> automation and remote control features.  It's also got a
character 
> generator that'll display 40 characters of text in the top 16 
> lines, and 
> I may add a parser for GPS data and I'll definitely allow 
> arbitrary text 
> to be entered through a serial port for telemetry and such.
> 
> I'm not thrilled with the camera module, but it was 
> reasonably easy to 
> interface.  If I'm going to stick with this camera, the big 
> question is 
> which lens to use.  There's at least some possibility to 
> allow the user 
> to select a lens, but the mechanical design will limit the 
> lens choice.
> 
> I'm currently using a 109 degree wide-angle lens.  It 
> captures a lot of 
> the scene, but it's hard to get much detail unless you're 
> really close, 
> and that introduces focus problems.  Anyone have any 
> suggestions on what 
> would be an appropriate FOV?
> 
> Also, any other deficiencies in the VC-H1 that I should try to
avoid 
> duplicating?
> 
> If I can get the transmitter to survive the high duty cycle, 
> I'm going 
> to try pairing one of my prototypes with an MX146 transmitter
and see 
> how small and light I can make a SSTV-capable high-altitude 
> balloon payload.
> 
> I'll at least have a demo running at Dayton, and maybe even
the first 
> batch of production units, but I'm not making any promises
yet.
> 
> Scott
> N1VG
> 
> VA7OTC JD Erskine wrote:
> > Scott Miller wrote:
> >> Is this list still active?  I can't find any archives.  And
is 
> >> discussion of the VC-H1 still on-topic?
> >>
> >> Scott
> >> N1VG
> > 
> > Appears to  be. I tried a search for VC-H1 on the TAPR site 
> and didn't 
> > find much.
> > 
> > 73 John/'JD'
> > VA7OTC VE0JD/mm
> > 
> > ---
> > 
> > 
> >     * To: "TAPR AO-16 APRS Special Interest Group" 
> > <ao16aprs at lists.tapr.org>
> >     * Subject: [ao16aprs] HTAPRS expanded for VC H1
> >     * From: "Horzepa, Stan" <Stan_Horzepa at adc.com>
> >     * Date: Mon, 15 Feb 1999 14:38:30 -0600
> >     * List-Owner: <mailto:owner-ao16aprs at lists.tapr.org>
> >     * List-Software: Lyris Server version 3.0
> >     * List-Subscribe:
<mailto:subscribe-ao16aprs at lists.tapr.org>
> >     * List-Unsubscribe:
<mailto:leave-ao16aprs-833L at lists.tapr.org>
> > 
> > The purpose of the TAPR HTAPRS SIG has been expanded to
include 
> > discussion of Kenwood's VC H1 (KenCam) and related issues, 
> such as the 
> > Automatic Picture Relay Network (APRN). So, talk among 
> yourselves about 
> > VC H1 on HTAPRS.
> > 
> > Stan, WA1LOU, *SIG administrator
> > 
> > _______________________________________________
> > htaprs mailing list
> > htaprs at lists.tapr.org
> > https://lists.tapr.org/cgi-bin/mailman/listinfo/htaprs
> > 
> > 
> 
> 
> _______________________________________________
> htaprs mailing list
> htaprs at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/htaprs
> 




From bruninga at usna.edu  Tue Feb 26 22:57:29 2008
From: bruninga at usna.edu (Robert Bruninga)
Date: Tue, 26 Feb 2008 17:57:29 -0500
Subject: [htaprs] VC-H1
In-Reply-To: <47C4749F.7010405@opentrac.org>
References: <47C4532A.2080902@opentrac.org> <47C45EB9.1030009@rac.ca>
	<014801c878b0$75e24740$42577a83@ewlab.usna.edu>
	<47C4749F.7010405@opentrac.org>
Message-ID: <01f301c878ca$f6d88110$42577a83@ewlab.usna.edu>

Scott,
Lets do it! 
You can add an APRS burst at the end of the SSTV tones, since
the TX is on, SQL is open and receiver is locked on.  The TXD
delay is not needed.  A complete APRN packet (mic-E) would take
less than 1/4 second or so...

One thing we can add to the APRN position packet is a special
definition for an SSTV Camera.  This way, we can use the COURSE
field to indicate the direction the camera is POINTING instead
of "moving"...  This will make APRN automated web pages show the
direction of the camera view, not just the position...  In fact,
we could use the SPEED field in this case as as field-of-view
angle.  This way, from each APRN view, we can PLOT the view
width on the map too!

Bob, Wb4APR


> -----Original Message-----
> From: Scott Miller [mailto:scott at opentrac.org] 
> Sent: Tuesday, February 26, 2008 3:21 PM
> To: bruninga at usna.edu; TAPR APRS Hot Topics Mailing List
> Subject: Re: [htaprs] VC-H1
> 
> Did anything ever happen with the APRN idea?  It wouldn't be 
> too hard to 
> add APRS capability to this thing - the processor is in the 
> same family 
> as the one in the OpenTracker+ (and the Tracker2) and much of 
> the code 
> could be ported straight over.
> 
> Scott
> N1VG
> 
> Robert Bruninga wrote:
> >> > Is this list still active?  
> >> > I can't find any archives.  And is 
> >> > discussion of the VC-H1 still on-topic?
> > 
> > I have several VC-H1's and rather than keeping them on the
> > shelves gathering dust, I now try to take them along with
plenty
> > of D7's to most local ham radio support events.
> > 
> > Even have one on a quick-mount plate for adding to the
county's
> > emergency operations comm truck for instant feed of video to
all
> > their intrnal monitors.
> > 
> > Bob, Wb4APR
> > 
> > 
> > _______________________________________________
> > htaprs mailing list
> > htaprs at lists.tapr.org
> > https://lists.tapr.org/cgi-bin/mailman/listinfo/htaprs
> > 
> > 
> 
> 




From scott at opentrac.org  Wed Feb 27 02:08:51 2008
From: scott at opentrac.org (Scott Miller)
Date: Tue, 26 Feb 2008 18:08:51 -0800
Subject: [htaprs] VC-H1
In-Reply-To: <005b01c878b8$b3ae0160$6807a8c0@JERRY>
References: <005b01c878b8$b3ae0160$6807a8c0@JERRY>
Message-ID: <47C4C633.70700@opentrac.org>

Trouble is I have very specific constraints for the camera, and I can't 
handle NTSC with this version.  The camera is a CMOS imager with an 
integrated JPEG processor, which also happens to output uncompressed 
RGB.  The serial interface lets me use cheap, slow memory.  If I could 
get it to send data in chunks like it does with JPEGs, I wouldn't even 
need any external memory at all.

For my next version, I'm planning to handle an 8-bit parallel BT.656 
interface with fast SRAM.  That'll mean spending about 4 times as much 
on memory (for 1/4 the capacity) and it'll occupy a lot more board space 
and I/O pins, but it also means that I can use an off-the-shelf 
NTSC/PAL/SECAM processor OR a typical cell phone type digital camera.

That version will also very likely have a 32-bit processor - it'll be 
worth the extra $4-7 for the stress and hair loss it'll prevent on my 
part.  I'm currently using an 8-bit chip at 14.7 MHz, and I'd be 
surprised if anyone has ever done real-time SSTV encoding with an 8-bit 
chip before.  I've got it working well in S1 mode, but I have some 
doubts about being able to get it to do Robot 36 - not only does it need 
to get data from the camera faster, but it also has to do RGB to YCbCr 
with chroma subsampling on the fly.

Assuming S1 mode (and maybe S2) is good enough, my problem is now 
packaging - what enclosure am I going to put the whole thing in, how do 
I mount the camera, what buttons will it have, where will they go, and 
where do the cables go?  I want to make a hand-held, battery-powered 
unit that could work with an HT.  Running the radio cable out the bottom 
is the most ergonomic choice there, but for most case designs you have 
interference with the battery compartment.  Injection molded plastic 
cases generally have sloping sides to facilitate ejection from the mold, 
so those are a pain to mount connectors in.

I'm considering putting the camera in a separate enclosure, and setting 
it up so it could be either mated directly with the encoder or remoted 
using a common cable.  It doesn't need to swivel like the VC-H1 (no 
need, with no screen) so a DB9 would probably work.  I could add an 
RS-232 transceiver on both ends to increase the maximum cable length, 
but I'm not sure it'd be worth the added complexity.

I think the next version with the NTSC/PAL interface will be in an 
extruded aluminum enclosure, and it'll certainly have RCA jacks and 
possibly S-video as well.  I can see the value of having a 
battery-powered version, though - you could clip it to your belt and 
plug a camcorder in to it, and just hit the 'send' button every time you 
want to send a still.

Scott
N1VG

Jerry N7YGE wrote:
> I have used this company for my fast scan ATV work for years.  
> http://www.supercircuits.com/index.asp
> 
> They have an excellent assortment of cameras.  You might want to contact
> them as to your specific needs.
> 
> If you are building a new black box, you might think about making it with
> RCA jacks so you can change out the camera easily.  You might want a Infa
> Red (IR) camera at times for night work.
> 
> Sounds like a fun project you have going.
> 
> Jerry N7YGE
> 
> 
> -----Original Message-----
> From: htaprs-bounces at lists.tapr.org [mailto:htaprs-bounces at lists.tapr.org]
> On Behalf Of Scott Miller
> Sent: Tuesday, February 26, 2008 11:33 AM
> To: TAPR APRS Hot Topics Mailing List
> Subject: Re: [htaprs] VC-H1
> 
> 
> Well, seeing as I can't find any other VC-H1 group, or even any active 
> SSTV group aside from MM-SSTV, I guess I'll ask this here.
> 
> My new project is up and running - it's a standalone SSTV encoder with 
> camera.  Sort of like a transmit-only VC-H1, but it'll have more 
> automation and remote control features.  It's also got a character 
> generator that'll display 40 characters of text in the top 16 lines, and 
> I may add a parser for GPS data and I'll definitely allow arbitrary text 
> to be entered through a serial port for telemetry and such.
> 
> I'm not thrilled with the camera module, but it was reasonably easy to 
> interface.  If I'm going to stick with this camera, the big question is 
> which lens to use.  There's at least some possibility to allow the user 
> to select a lens, but the mechanical design will limit the lens choice.
> 
> I'm currently using a 109 degree wide-angle lens.  It captures a lot of 
> the scene, but it's hard to get much detail unless you're really close, 
> and that introduces focus problems.  Anyone have any suggestions on what 
> would be an appropriate FOV?
> 
> Also, any other deficiencies in the VC-H1 that I should try to avoid 
> duplicating?
> 
> If I can get the transmitter to survive the high duty cycle, I'm going 
> to try pairing one of my prototypes with an MX146 transmitter and see 
> how small and light I can make a SSTV-capable high-altitude balloon payload.
> 
> I'll at least have a demo running at Dayton, and maybe even the first 
> batch of production units, but I'm not making any promises yet.
> 
> Scott
> N1VG
> 
> VA7OTC JD Erskine wrote:
>> Scott Miller wrote:
>>> Is this list still active?  I can't find any archives.  And is
>>> discussion of the VC-H1 still on-topic?
>>>
>>> Scott
>>> N1VG
>> 
>> Appears to  be. I tried a search for VC-H1 on the TAPR site and didn't
>> find much.
>> 
>> 73 John/'JD'
>> VA7OTC VE0JD/mm
>> 
>> ---
>> 
>> 
>>     * To: "TAPR AO-16 APRS Special Interest Group"
>> <ao16aprs at lists.tapr.org>
>>     * Subject: [ao16aprs] HTAPRS expanded for VC H1
>>     * From: "Horzepa, Stan" <Stan_Horzepa at adc.com>
>>     * Date: Mon, 15 Feb 1999 14:38:30 -0600
>>     * List-Owner: <mailto:owner-ao16aprs at lists.tapr.org>
>>     * List-Software: Lyris Server version 3.0
>>     * List-Subscribe: <mailto:subscribe-ao16aprs at lists.tapr.org>
>>     * List-Unsubscribe: <mailto:leave-ao16aprs-833L at lists.tapr.org>
>> 
>> The purpose of the TAPR HTAPRS SIG has been expanded to include
>> discussion of Kenwood's VC H1 (KenCam) and related issues, such as the 
>> Automatic Picture Relay Network (APRN). So, talk among yourselves about 
>> VC H1 on HTAPRS.
>> 
>> Stan, WA1LOU, *SIG administrator
>> 
>> _______________________________________________
>> htaprs mailing list
>> htaprs at lists.tapr.org 
>> https://lists.tapr.org/cgi-bin/mailman/listinfo/htaprs
>> 
>> 
> 
> 
> _______________________________________________
> htaprs mailing list
> htaprs at lists.tapr.org https://lists.tapr.org/cgi-bin/mailman/listinfo/htaprs
> 
> 
> 
> _______________________________________________
> htaprs mailing list
> htaprs at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/htaprs
> 
> 




From scott at opentrac.org  Wed Feb 27 04:10:33 2008
From: scott at opentrac.org (Scott Miller)
Date: Tue, 26 Feb 2008 20:10:33 -0800
Subject: [htaprs] VC-H1
In-Reply-To: <47C493F1.11878.FFB71D@kb2scs.optonline.net>
References: <47C4532A.2080902@opentrac.org> <47C4749F.7010405@opentrac.org>
	<01ed01c878c9$5f2c2f70$42577a83@ewlab.usna.edu>
	<47C493F1.11878.FFB71D@kb2scs.optonline.net>
Message-ID: <47C4E2B9.5030800@opentrac.org>

I think this whole system would be more interesting if there was an 
APRS-IS equivalent for images.  The big problem I see with that is that 
not all received images will be identical, if more than one receiver 
hears a frame.  Still, it'd be really cool to see camera icons on the 
APRS.fi map that would bring up pictures.

Robot 36 is starting to look a little more doable - I found a very 
non-standard baud rate that both the camera and the processor can 
support, which gets the data out of the camera in 40 seconds instead of 
53 and lets the MCU run at almost its maximum rated 20 MHz clock speed. 
  Flash timing constraints still introduce some headaches, but at least 
I've got more clock cycles to work with, even if it does mean a bit of 
on-the-fly clock generator tweaking.

The camera will still need a 4-second head start on the image 
transmission, but the transmit delay and VIS will eat up part of that. 
I don't think a 2-3 second delay before transmission is unreasonable. 
It could also be used for a CW ID since Robot 36 apparently doesn't have 
the 16-line calibration area I'm using for the character generator.

Now to find an efficient way to do RGB to YCbCr conversion without 
floating point math, not a lot of space for lookup tables, and maybe not 
enough RAM to hold an extra line of subsampled chroma data!

Still, there's nothing like implementing a mode from scratch to get a 
real understanding of how it all works!

Scott
N1VG

kb2scs at optonline.net wrote:
> Hi Bob
>            How soon we forget.
> I am the one who has a working APRN system/software.
> The software can be found at 
> http://www.qsl.net/kb2scs
> 
> There are quite a few people using this system.software.
> 
> I am all for anything new that Scott can come up with. But would like 
> the APRN system that is in place not to be abandoned.
> 
> On 26 Feb 2008 at 17:46, Robert Bruninga wrote:
> 
>> > Did anything ever happen with the APRN idea?  
>> 
>> Not that I remember.  There was one individual that had
>> something working, but I 'm not sure I can find the link.  The
>> concept was great if we are going to use SSTV, and that is that
>> APRS provided the ability to LABEL the pictures, and assign them
>> a POSITION...
>> 
>> > It wouldn't be too hard to add APRS capability 
>> > to this thing - the processor is in the 
>> > same family as the one in the OpenTracker+ 
>> > (and the Tracker2) and much of 
>> > the code could be ported straight over.
>> 
>> Not sure how many people still have them.  And not being in
>> production is a sever limitation to future apps.  However, there
>> are LOTS of SSTV packages for laptops with sound cards... Maybe
>> there is wehre the application should really apply.  Then you
>> don't need a processor, since the same PC can geenerate the APRS
>> tones as well as the SSTV tones.
>> 
>> Maybe we just need to lean on the SSTV code authors to add APRS
>> labels an dposits to each picture?
>> 
>> Bob
>> 
> 
> Let us hope we never witness the "Silence Of The Hams"
> 73 DE John  KB2SCS
>        E-Mail:            kb2scs at arrl.net
>        APRS-SCS     http://www.tapr.org/~kb2scs
>        Web Page:     http://www.qsl.net/kb2scs
> 
> 





From kb2scs at optonline.net  Wed Feb 27 03:34:25 2008
From: kb2scs at optonline.net (kb2scs at optonline.net)
Date: Tue, 26 Feb 2008 22:34:25 -0500
Subject: [htaprs] VC-H1
In-Reply-To: <01ed01c878c9$5f2c2f70$42577a83@ewlab.usna.edu>
References: <47C4532A.2080902@opentrac.org> <47C4749F.7010405@opentrac.org>
	<01ed01c878c9$5f2c2f70$42577a83@ewlab.usna.edu>
Message-ID: <47C493F1.11878.FFB71D@kb2scs.optonline.net>

Hi Bob
           How soon we forget.
I am the one who has a working APRN system/software.
The software can be found at 
http://www.qsl.net/kb2scs

There are quite a few people using this system.software.

I am all for anything new that Scott can come up with. But would like 
the APRN system that is in place not to be abandoned.

On 26 Feb 2008 at 17:46, Robert Bruninga wrote:

> > Did anything ever happen with the APRN idea?  
> 
> Not that I remember.  There was one individual that had
> something working, but I 'm not sure I can find the link.  The
> concept was great if we are going to use SSTV, and that is that
> APRS provided the ability to LABEL the pictures, and assign them
> a POSITION...
> 
> > It wouldn't be too hard to add APRS capability 
> > to this thing - the processor is in the 
> > same family as the one in the OpenTracker+ 
> > (and the Tracker2) and much of 
> > the code could be ported straight over.
> 
> Not sure how many people still have them.  And not being in
> production is a sever limitation to future apps.  However, there
> are LOTS of SSTV packages for laptops with sound cards... Maybe
> there is wehre the application should really apply.  Then you
> don't need a processor, since the same PC can geenerate the APRS
> tones as well as the SSTV tones.
> 
> Maybe we just need to lean on the SSTV code authors to add APRS
> labels an dposits to each picture?
> 
> Bob
> 

Let us hope we never witness the "Silence Of The Hams"
73 DE John  KB2SCS
       E-Mail:            kb2scs at arrl.net
       APRS-SCS     http://www.tapr.org/~kb2scs
       Web Page:     http://www.qsl.net/kb2scs



From HamLists at ametx.com  Wed Feb 27 11:57:16 2008
From: HamLists at ametx.com (AE5PL Lists)
Date: Wed, 27 Feb 2008 05:57:16 -0600
Subject: [htaprs] VC-H1
In-Reply-To: <C9EF23045BD16A44A7B86F595C41536125E7B8@amewebsrvr.webametx.local>
References: <47C4532A.2080902@opentrac.org>
	<47C4749F.7010405@opentrac.org><01ed01c878c9$5f2c2f70$42577a83@ewlab.usna.edu><47C493F1.11878.FFB71D@kb2scs.optonline.net>
	<C9EF23045BD16A44A7B86F595C41536125E7B8@amewebsrvr.webametx.local>
Message-ID: <478F6623898BBC4DBD692A223D28298A2598D8@amewebsrvr.webametx.local>

Please don't look to use APRS-IS as a transport for images.  It is not
designed to do this and would be a significant bandwidth issue to server
operators.

73,

Pete Loveall AE5PL
pete at ae5pl dot net

> -----Original Message-----
> From: Scott Miller
> Posted At: Tuesday, February 26, 2008 10:12 PM
> Subject: Re: [htaprs] VC-H1
> 
> I think this whole system would be more interesting if there was an
> APRS-IS equivalent for images.  The big problem I see with that is
that
> not all received images will be identical, if more than one receiver
> hears a frame.  Still, it'd be really cool to see camera icons on the
> APRS.fi map that would bring up pictures.



From scott at opentrac.org  Wed Feb 27 14:48:28 2008
From: scott at opentrac.org (Scott Miller)
Date: Wed, 27 Feb 2008 06:48:28 -0800
Subject: [htaprs] VC-H1
In-Reply-To: <478F6623898BBC4DBD692A223D28298A2598D8@amewebsrvr.webametx.local>
References: <47C4532A.2080902@opentrac.org>	<47C4749F.7010405@opentrac.org><01ed01c878c9$5f2c2f70$42577a83@ewlab.usna.edu><47C493F1.11878.FFB71D@kb2scs.optonline.net>	<C9EF23045BD16A44A7B86F595C41536125E7B8@amewebsrvr.webametx.local>
	<478F6623898BBC4DBD692A223D28298A2598D8@amewebsrvr.webametx.local>
Message-ID: <47C5783C.4000009@opentrac.org>

I didn't mean using the APRS-IS itself.  I'm talking about a similar 
distribution system.  Only I don't think it'd be wise to send everything 
to everyone - just replicate the images in the core and allow clients to 
retrieve them by request.  Or maybe only share pointers to images and 
let everyone host what they receive.

Scott
N1VG

AE5PL Lists wrote:
> Please don't look to use APRS-IS as a transport for images.  It is not
> designed to do this and would be a significant bandwidth issue to server
> operators.
> 
> 73,
> 
> Pete Loveall AE5PL
> pete at ae5pl dot net
> 
>> -----Original Message-----
>> From: Scott Miller
>> Posted At: Tuesday, February 26, 2008 10:12 PM
>> Subject: Re: [htaprs] VC-H1
>> 
>> I think this whole system would be more interesting if there was an
>> APRS-IS equivalent for images.  The big problem I see with that is
> that
>> not all received images will be identical, if more than one receiver
>> hears a frame.  Still, it'd be really cool to see camera icons on the
>> APRS.fi map that would bring up pictures.
> 
> _______________________________________________
> htaprs mailing list
> htaprs at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/htaprs
> 
> 




From HamLists at ametx.com  Wed Feb 27 15:43:37 2008
From: HamLists at ametx.com (AE5PL Lists)
Date: Wed, 27 Feb 2008 09:43:37 -0600
Subject: [htaprs] VC-H1
In-Reply-To: <C9EF23045BD16A44A7B86F595C41536125E7CE@amewebsrvr.webametx.local>
References: <47C4532A.2080902@opentrac.org>	<47C4749F.7010405@opentrac.org><01ed01c878c9$5f2c2f70$42577a83@ewlab.usna.edu><47C493F1.11878.FFB71D@kb2scs.optonline.net>	<C9EF23045BD16A44A7B86F595C41536125E7B8@amewebsrvr.webametx.local><478F6623898BBC4DBD692A223D28298A2598D8@amewebsrvr.webametx.local>
	<C9EF23045BD16A44A7B86F595C41536125E7CE@amewebsrvr.webametx.local>
Message-ID: <478F6623898BBC4DBD692A223D28298A2598DB@amewebsrvr.webametx.local>

Ok, I understand now.  Sorry about the confusion on my part.

73,

Pete Loveall AE5PL
pete at ae5pl dot net

> -----Original Message-----
> From: Scott Miller
> Posted At: Wednesday, February 27, 2008 9:19 AM
> Subject: Re: [htaprs] VC-H1
> 
> I didn't mean using the APRS-IS itself.  I'm talking about a similar
> distribution system.  Only I don't think it'd be wise to send
> everything
> to everyone - just replicate the images in the core and allow clients
> to
> retrieve them by request.  Or maybe only share pointers to images and
> let everyone host what they receive.



From bruninga at usna.edu  Wed Feb 27 17:14:07 2008
From: bruninga at usna.edu (Robert Bruninga)
Date: Wed, 27 Feb 2008 12:14:07 -0500
Subject: [htaprs] VC-H1 APRN network
In-Reply-To: <47C5783C.4000009@opentrac.org>
References: <47C4532A.2080902@opentrac.org>	<47C4749F.7010405@opentrac.org><01ed01c878c9$5f2c2f70$42577a83@ewlab.usna.edu><47C493F1.11878.FFB71D@kb2scs.optonline.net>	<C9EF23045BD16A44A7B86F595C41536125E7B8@amewebsrvr.webametx.local><478F6623898BBC4DBD692A223D28298A2598D8@amewebsrvr.webametx.local>
	<47C5783C.4000009@opentrac.org>
Message-ID: <024401c87964$2965d850$42577a83@ewlab.usna.edu>

> I didn't mean using the APRS-IS itself.  
> I'm talking about a similar distribution 
> system.  Only I don't think it'd be wise to 
> send everything to everyone - just replicate 
> the images in the core and allow clients to 
> retrieve them by request. 

Yes, the original concept of the APRN was a local piece of
software (think Igate) that monitored a local area channel
(channels) and collected all SSTV live images with APRS tags on
them for labeling and retrieval.  Then the images were available
on the WEB locally from that server via a unique URL.  But also
like an Igate, this APRN node forwards that packet LABEL along
with the URL into a central global APRN server.

So the images are kept locally for local access (Via RF or local
WEB) but the links and pointers to those images are contained in
a single packet that is available globally.

Come to think about it, that one packet per image would not be
an unnecessary burden on the existing APRS global network.  SO
although I initinally was thinking about a separate APRN
distribution system, now I think that with just one packet per
image, that we shoud consider it on the APRS network.

Since each image was accepted and filed at the local APRN node
with its "APRS" tag, then the images can be retrieved locally
by:
1) By callsign
2) By area (by location)
3) by orientation (view west, etc)
4) by subject (fire, flood, power line, etc...)

Since the URL was distributed in the same packet.

> Or maybe only share pointers to images and 
> let everyone host what they receive.

Next email will address format of that one packet:

Bob, WB4APR




From bruninga at usna.edu  Wed Feb 27 17:24:57 2008
From: bruninga at usna.edu (Robert Bruninga)
Date: Wed, 27 Feb 2008 12:24:57 -0500
Subject: [htaprs] VC-H1 APRN network
In-Reply-To: <024401c87964$2965d850$42577a83@ewlab.usna.edu>
References: <47C4532A.2080902@opentrac.org>	<47C4749F.7010405@opentrac.org><01ed01c878c9$5f2c2f70$42577a83@ewlab.usna.edu><47C493F1.11878.FFB71D@kb2scs.optonline.net>	<C9EF23045BD16A44A7B86F595C41536125E7B8@amewebsrvr.webametx.local><478F6623898BBC4DBD692A223D28298A2598D8@amewebsrvr.webametx.local><47C5783C.4000009@opentrac.org>
	<024401c87964$2965d850$42577a83@ewlab.usna.edu>
Message-ID: <024501c87965$ac73b0e0$42577a83@ewlab.usna.edu>

As far as the packet format for the APRN images, I propose
something like the following:

1) Mic-E format for brevity
2) Appended on the end of the SSTV tones
3) Needs no TXD
4) Mic-E contains normal LAT/LONG, SYMBOL, CSE/SPD fields
5) SYMBOL is a special SSTV APRN symbol
6) That symbol (by definition) re-defines the CSE/SPD fields as
VIEW-DIRECTION and VIEW-ANGLE.  View direction being 0-360
degrees.  And view angle being 0-360 degrees (though typically
about 60 degrees for a normal wide angle shot)...

On receipt of that packet, the APRN node stores the SSTV image
and all of the above data.  It assigns a URL to that image and
data.  And it APPENDS that URL onto the end of the original
Mic-E packet text.  AND THEN it injects that one packet into the
APRS-IS.  Being Mic-E, it is decodable on all existing APRS if
monitored direct.

Notice, that I do NOT EVER anticipate that these APRN SSTV
images will be transmitted on any APRS channel.  The UPLINK
channel to the local APRN node is always some other channel.
Anything from HF to microwave to 146.52...  But never APRS
channel.  There are many reasons for that.
1) Obviously, 40 sec Xmissions are not welcome on APRS channel
2) the SSTV image would be corrupted by collisions
3) we don't want normal Igates picking up the Mic-E APRN packets
because they would blindly forward the packet and it woiuld go
into the APRS-IS without the necessary URL that should come from
the APRN node.
4) the APRN node does not Igate the APRN packet until it has
appended the URL to the packet.

Something like that.
Bob, Wb4APR 

> -----Original Message-----
> From: htaprs-bounces at lists.tapr.org 
> [mailto:htaprs-bounces at lists.tapr.org] On Behalf Of Robert
Bruninga
> Sent: Wednesday, February 27, 2008 12:14 PM
> To: 'TAPR APRS Hot Topics Mailing List'
> Subject: RE: [htaprs] VC-H1 APRN network
> 
> > I didn't mean using the APRS-IS itself.  
> > I'm talking about a similar distribution 
> > system.  Only I don't think it'd be wise to 
> > send everything to everyone - just replicate 
> > the images in the core and allow clients to 
> > retrieve them by request. 
> 
> Yes, the original concept of the APRN was a local piece of
> software (think Igate) that monitored a local area channel
> (channels) and collected all SSTV live images with APRS tags
on
> them for labeling and retrieval.  Then the images were
available
> on the WEB locally from that server via a unique URL.  But
also
> like an Igate, this APRN node forwards that packet LABEL along
> with the URL into a central global APRN server.
> 
> So the images are kept locally for local access (Via RF or
local
> WEB) but the links and pointers to those images are contained
in
> a single packet that is available globally.
> 
> Come to think about it, that one packet per image would not be
> an unnecessary burden on the existing APRS global network.  SO
> although I initinally was thinking about a separate APRN
> distribution system, now I think that with just one packet per
> image, that we shoud consider it on the APRS network.
> 
> Since each image was accepted and filed at the local APRN node
> with its "APRS" tag, then the images can be retrieved locally
> by:
> 1) By callsign
> 2) By area (by location)
> 3) by orientation (view west, etc)
> 4) by subject (fire, flood, power line, etc...)
> 
> Since the URL was distributed in the same packet.
> 
> > Or maybe only share pointers to images and 
> > let everyone host what they receive.
> 
> Next email will address format of that one packet:
> 
> Bob, WB4APR
> 
> 
> _______________________________________________
> htaprs mailing list
> htaprs at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/htaprs
> 




From bruninga at usna.edu  Wed Feb 27 18:40:53 2008
From: bruninga at usna.edu (Robert Bruninga)
Date: Wed, 27 Feb 2008 13:40:53 -0500
Subject: [htaprs] VC-H1 APRN network
In-Reply-To: <024501c87965$ac73b0e0$42577a83@ewlab.usna.edu>
References: <47C4532A.2080902@opentrac.org>	<47C4749F.7010405@opentrac.org><01ed01c878c9$5f2c2f70$42577a83@ewlab.usna.edu><47C493F1.11878.FFB71D@kb2scs.optonline.net>	<C9EF23045BD16A44A7B86F595C41536125E7B8@amewebsrvr.webametx.local><478F6623898BBC4DBD692A223D28298A2598D8@amewebsrvr.webametx.local><47C5783C.4000009@opentrac.org>
	<024401c87964$2965d850$42577a83@ewlab.usna.edu>
	<024501c87965$ac73b0e0$42577a83@ewlab.usna.edu>
Message-ID: <025401c87970$486ead10$42577a83@ewlab.usna.edu>

Scott and John,

I have just taken a look and refreshed some dated material on my
APRN web page:
http://web.usna.navy.mil/~bruninga/aprntxt.html

And what would be nice would be to be able to add some images to
that rather dull site.  John, Do you have any APRN screen shots,
and, scott, let me know when you have any pictures of the new
hardware.

Bob, Wb4APR 

> -----Original Message-----
> From: Robert Bruninga [mailto:bruninga at usna.edu] 
> Sent: Wednesday, February 27, 2008 12:25 PM
> To: bruninga at usna.edu; 'TAPR APRS Hot Topics Mailing List'
> Subject: RE: [htaprs] VC-H1 APRN network
> 
> As far as the packet format for the APRN images, I propose
> something like the following:
> 
> 1) Mic-E format for brevity
> 2) Appended on the end of the SSTV tones
> 3) Needs no TXD
> 4) Mic-E contains normal LAT/LONG, SYMBOL, CSE/SPD fields
> 5) SYMBOL is a special SSTV APRN symbol
> 6) That symbol (by definition) re-defines the CSE/SPD fields
as
> VIEW-DIRECTION and VIEW-ANGLE.  View direction being 0-360
> degrees.  And view angle being 0-360 degrees (though typically
> about 60 degrees for a normal wide angle shot)...
> 
> On receipt of that packet, the APRN node stores the SSTV image
> and all of the above data.  It assigns a URL to that image and
> data.  And it APPENDS that URL onto the end of the original
> Mic-E packet text.  AND THEN it injects that one packet into
the
> APRS-IS.  Being Mic-E, it is decodable on all existing APRS if
> monitored direct.
> 
> Notice, that I do NOT EVER anticipate that these APRN SSTV
> images will be transmitted on any APRS channel.  The UPLINK
> channel to the local APRN node is always some other channel.
> Anything from HF to microwave to 146.52...  But never APRS
> channel.  There are many reasons for that.
> 1) Obviously, 40 sec Xmissions are not welcome on APRS channel
> 2) the SSTV image would be corrupted by collisions
> 3) we don't want normal Igates picking up the Mic-E APRN
packets
> because they would blindly forward the packet and it woiuld go
> into the APRS-IS without the necessary URL that should come
from
> the APRN node.
> 4) the APRN node does not Igate the APRN packet until it has
> appended the URL to the packet.
> 
> Something like that.
> Bob, Wb4APR 
> 
> > -----Original Message-----
> > From: htaprs-bounces at lists.tapr.org 
> > [mailto:htaprs-bounces at lists.tapr.org] On Behalf Of Robert
> Bruninga
> > Sent: Wednesday, February 27, 2008 12:14 PM
> > To: 'TAPR APRS Hot Topics Mailing List'
> > Subject: RE: [htaprs] VC-H1 APRN network
> > 
> > > I didn't mean using the APRS-IS itself.  
> > > I'm talking about a similar distribution 
> > > system.  Only I don't think it'd be wise to 
> > > send everything to everyone - just replicate 
> > > the images in the core and allow clients to 
> > > retrieve them by request. 
> > 
> > Yes, the original concept of the APRN was a local piece of
> > software (think Igate) that monitored a local area channel
> > (channels) and collected all SSTV live images with APRS tags
> on
> > them for labeling and retrieval.  Then the images were
> available
> > on the WEB locally from that server via a unique URL.  But
> also
> > like an Igate, this APRN node forwards that packet LABEL
along
> > with the URL into a central global APRN server.
> > 
> > So the images are kept locally for local access (Via RF or
> local
> > WEB) but the links and pointers to those images are
contained
> in
> > a single packet that is available globally.
> > 
> > Come to think about it, that one packet per image would not
be
> > an unnecessary burden on the existing APRS global network.
SO
> > although I initinally was thinking about a separate APRN
> > distribution system, now I think that with just one packet
per
> > image, that we shoud consider it on the APRS network.
> > 
> > Since each image was accepted and filed at the local APRN
node
> > with its "APRS" tag, then the images can be retrieved
locally
> > by:
> > 1) By callsign
> > 2) By area (by location)
> > 3) by orientation (view west, etc)
> > 4) by subject (fire, flood, power line, etc...)
> > 
> > Since the URL was distributed in the same packet.
> > 
> > > Or maybe only share pointers to images and 
> > > let everyone host what they receive.
> > 
> > Next email will address format of that one packet:
> > 
> > Bob, WB4APR
> > 
> > 
> > _______________________________________________
> > htaprs mailing list
> > htaprs at lists.tapr.org
> > https://lists.tapr.org/cgi-bin/mailman/listinfo/htaprs
> > 
> 
> 




From HamLists at ametx.com  Wed Feb 27 19:50:20 2008
From: HamLists at ametx.com (AE5PL Lists)
Date: Wed, 27 Feb 2008 13:50:20 -0600
Subject: [htaprs] VC-H1 APRN network
In-Reply-To: <C9EF23045BD16A44A7B86F595C41536125E7DA@amewebsrvr.webametx.local>
References: <47C4532A.2080902@opentrac.org>	<47C4749F.7010405@opentrac.org><01ed01c878c9$5f2c2f70$42577a83@ewlab.usna.edu><47C493F1.11878.FFB71D@kb2scs.optonline.net>	<C9EF23045BD16A44A7B86F595C41536125E7B8@amewebsrvr.webametx.local><478F6623898BBC4DBD692A223D28298A2598D8@amewebsrvr.webametx.local><47C5783C.4000009@opentrac.org>
	<C9EF23045BD16A44A7B86F595C41536125E7DA@amewebsrvr.webametx.local>
Message-ID: <478F6623898BBC4DBD692A223D28298A2598DE@amewebsrvr.webametx.local>

Let me repeat: Do NOT even consider using APRS-IS for this.  It does not
transport "packets".  It transports TNC2 format text lines.  Scott was
correct in his original statement.

73,

Pete Loveall AE5PL
www.ae5pl.net


> -----Original Message-----
> From: Robert Bruninga
> Posted At: Wednesday, February 27, 2008 11:14 AM
> Posted To: AE5PL
> Conversation: [htaprs] VC-H1 APRN network
> Subject: RE: [htaprs] VC-H1 APRN network
> 
> > I didn't mean using the APRS-IS itself.
> > I'm talking about a similar distribution
> > system.  Only I don't think it'd be wise to
> > send everything to everyone - just replicate
> > the images in the core and allow clients to
> > retrieve them by request.
> 
> Come to think about it, that one packet per image would not be
> an unnecessary burden on the existing APRS global network.  SO
> although I initinally was thinking about a separate APRN
> distribution system, now I think that with just one packet per
> image, that we shoud consider it on the APRS network.



From bruninga at usna.edu  Wed Feb 27 20:57:00 2008
From: bruninga at usna.edu (Robert Bruninga)
Date: Wed, 27 Feb 2008 15:57:00 -0500
Subject: [htaprs] VC-H1 APRN network
In-Reply-To: <478F6623898BBC4DBD692A223D28298A2598DE@amewebsrvr.webametx.local>
References: <47C4532A.2080902@opentrac.org>	<47C4749F.7010405@opentrac.org><01ed01c878c9$5f2c2f70$42577a83@ewlab.usna.edu><47C493F1.11878.FFB71D@kb2scs.optonline.net>	<C9EF23045BD16A44A7B86F595C41536125E7B8@amewebsrvr.webametx.local><478F6623898BBC4DBD692A223D28298A2598D8@amewebsrvr.webametx.local><47C5783C.4000009@opentrac.org><C9EF23045BD16A44A7B86F595C41536125E7DA@amewebsrvr.webametx.local>
	<478F6623898BBC4DBD692A223D28298A2598DE@amewebsrvr.webametx.local>
Message-ID: <026001c87983$4bf60470$42577a83@ewlab.usna.edu>

> Let me repeat: Do NOT even consider using 
> APRS-IS for this.  It does not
> transport "packets".  It transports TNC2 
> format text lines.  Scott was
> correct in his original statement.

Pete, I think you are missinterpreting what I was saying...

> > Come to think about it, that one packet per image 
> > would not be an unnecessary burden on the existing 
> > APRS global network.

We are not sending an "image packet".  What we would be sending
on the APRS-IS network is a single Mic-E position packet
whenever a new image is uploaded to an APRN node.  That packet
is a standard Mic-E packet generated by the handheld D7 HT with
these existing standard fields:

CALL, LAT/LONG/CSE/SPD and STATUS TEXT.  The only thing unique
to this application is that the "status text" contains a URL
that points to where the image can be viewed.

It is no different from any other position packet from any other
D7, except for the length of the URL on the end.

Hope that eases your concerns.
Bob, Wb4APR




From HamLists at ametx.com  Wed Feb 27 21:24:08 2008
From: HamLists at ametx.com (AE5PL Lists)
Date: Wed, 27 Feb 2008 15:24:08 -0600
Subject: [htaprs] VC-H1 APRN network
In-Reply-To: <C9EF23045BD16A44A7B86F595C41536125E7EA@amewebsrvr.webametx.local>
References: <47C4532A.2080902@opentrac.org>	<47C4749F.7010405@opentrac.org><01ed01c878c9$5f2c2f70$42577a83@ewlab.usna.edu><47C493F1.11878.FFB71D@kb2scs.optonline.net>	<C9EF23045BD16A44A7B86F595C41536125E7B8@amewebsrvr.webametx.local><478F6623898BBC4DBD692A223D28298A2598D8@amewebsrvr.webametx.local><47C5783C.4000009@opentrac.org><C9EF23045BD16A44A7B86F595C41536125E7DA@amewebsrvr.webametx.local><478F6623898BBC4DBD692A223D28298A2598DE@amewebsrvr.webametx.local>
	<C9EF23045BD16A44A7B86F595C41536125E7EA@amewebsrvr.webametx.local>
Message-ID: <478F6623898BBC4DBD692A223D28298A2598E0@amewebsrvr.webametx.local>

Then why use APRS-IS at all?  Why not send this, as Scott recommended,
directly to the APRN server(s).  The information does no good on APRS
and would require a more complex "IGate" configuration requiring the
APRN IGate to connect to both APRS-IS and to the APRN servers.  Keep it
simple.

73,

Pete Loveall AE5PL
pete at ae5pl dot net

> -----Original Message-----
> From: Robert Bruninga
> Posted At: Wednesday, February 27, 2008 2:57 PM
> Subject: RE: [htaprs] VC-H1 APRN network
> 
> We are not sending an "image packet".  What we would be sending
> on the APRS-IS network is a single Mic-E position packet
> whenever a new image is uploaded to an APRN node.  That packet
> is a standard Mic-E packet generated by the handheld D7 HT with
> these existing standard fields:
> 
> CALL, LAT/LONG/CSE/SPD and STATUS TEXT.  The only thing unique
> to this application is that the "status text" contains a URL
> that points to where the image can be viewed.
> 
> It is no different from any other position packet from any other
> D7, except for the length of the URL on the end.



From HamLists at ametx.com  Wed Feb 27 21:26:26 2008
From: HamLists at ametx.com (AE5PL Lists)
Date: Wed, 27 Feb 2008 15:26:26 -0600
Subject: [htaprs] VC-H1 APRN network
References: <47C4532A.2080902@opentrac.org>	<47C4749F.7010405@opentrac.org><01ed01c878c9$5f2c2f70$42577a83@ewlab.usna.edu><47C493F1.11878.FFB71D@kb2scs.optonline.net>	<C9EF23045BD16A44A7B86F595C41536125E7B8@amewebsrvr.webametx.local><478F6623898BBC4DBD692A223D28298A2598D8@amewebsrvr.webametx.local><47C5783C.4000009@opentrac.org><C9EF23045BD16A44A7B86F595C41536125E7DA@amewebsrvr.webametx.local><478F6623898BBC4DBD692A223D28298A2598DE@amewebsrvr.webametx.local>
	<C9EF23045BD16A44A7B86F595C41536125E7EA@amewebsrvr.webametx.local>
Message-ID: <478F6623898BBC4DBD692A223D28298A2598E1@amewebsrvr.webametx.local>

Also, the method Scott described would require no knowledge on the part
of the sender as to putting a URL in the posit since that would be at
the APRN servers.  Shorter transmissions.

73,

Pete Loveall AE5PL
pete at ae5pl dot net


> -----Original Message-----
> From: AE5PL Lists
> Sent: Wednesday, February 27, 2008 3:24 PM
> To: 'TAPR APRS Hot Topics Mailing List'
> Subject: RE: [htaprs] VC-H1 APRN network
> 
> Then why use APRS-IS at all?  Why not send this, as Scott recommended,
> directly to the APRN server(s).  The information does no good on APRS
> and would require a more complex "IGate" configuration requiring the
> APRN IGate to connect to both APRS-IS and to the APRN servers.  Keep
it
> simple.
> 
> 73,
> 
> Pete Loveall AE5PL
> pete at ae5pl dot net
> 
> > -----Original Message-----
> > From: Robert Bruninga
> > Posted At: Wednesday, February 27, 2008 2:57 PM
> > Subject: RE: [htaprs] VC-H1 APRN network
> >
> > We are not sending an "image packet".  What we would be sending
> > on the APRS-IS network is a single Mic-E position packet
> > whenever a new image is uploaded to an APRN node.  That packet
> > is a standard Mic-E packet generated by the handheld D7 HT with
> > these existing standard fields:
> >
> > CALL, LAT/LONG/CSE/SPD and STATUS TEXT.  The only thing unique
> > to this application is that the "status text" contains a URL
> > that points to where the image can be viewed.
> >
> > It is no different from any other position packet from any other
> > D7, except for the length of the URL on the end.



From scott at opentrac.org  Wed Feb 27 21:30:00 2008
From: scott at opentrac.org (Scott Miller)
Date: Wed, 27 Feb 2008 13:30:00 -0800
Subject: [htaprs] VC-H1 APRN network
In-Reply-To: <478F6623898BBC4DBD692A223D28298A2598E0@amewebsrvr.webametx.local>
References: <47C4532A.2080902@opentrac.org>	<47C4749F.7010405@opentrac.org><01ed01c878c9$5f2c2f70$42577a83@ewlab.usna.edu><47C493F1.11878.FFB71D@kb2scs.optonline.net>	<C9EF23045BD16A44A7B86F595C41536125E7B8@amewebsrvr.webametx.local><478F6623898BBC4DBD692A223D28298A2598D8@amewebsrvr.webametx.local><47C5783C.4000009@opentrac.org><C9EF23045BD16A44A7B86F595C41536125E7DA@amewebsrvr.webametx.local><478F6623898BBC4DBD692A223D28298A2598DE@amewebsrvr.webametx.local>	<C9EF23045BD16A44A7B86F595C41536125E7EA@amewebsrvr.webametx.local>
	<478F6623898BBC4DBD692A223D28298A2598E0@amewebsrvr.webametx.local>
Message-ID: <47C5D658.6020502@opentrac.org>

I don't care where everything is stored, I just want it to show up on 
the map at aprs.fi when there are pictures.  To me, that means a custom 
APRS message format with appropriate identification information.  I 
think Bob's talking about the same thing, but I haven't had a chance to 
digest all of his suggestions so far.

Maybe what we need is a more generalized resource tagging format.

Scott
N1VG

AE5PL Lists wrote:
> Then why use APRS-IS at all?  Why not send this, as Scott recommended,
> directly to the APRN server(s).  The information does no good on APRS
> and would require a more complex "IGate" configuration requiring the
> APRN IGate to connect to both APRS-IS and to the APRN servers.  Keep it
> simple.
> 
> 73,
> 
> Pete Loveall AE5PL
> pete at ae5pl dot net
> 
>> -----Original Message-----
>> From: Robert Bruninga
>> Posted At: Wednesday, February 27, 2008 2:57 PM
>> Subject: RE: [htaprs] VC-H1 APRN network
>> 
>> We are not sending an "image packet".  What we would be sending
>> on the APRS-IS network is a single Mic-E position packet
>> whenever a new image is uploaded to an APRN node.  That packet
>> is a standard Mic-E packet generated by the handheld D7 HT with
>> these existing standard fields:
>> 
>> CALL, LAT/LONG/CSE/SPD and STATUS TEXT.  The only thing unique
>> to this application is that the "status text" contains a URL
>> that points to where the image can be viewed.
>> 
>> It is no different from any other position packet from any other
>> D7, except for the length of the URL on the end.
> 
> _______________________________________________
> htaprs mailing list
> htaprs at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/htaprs
> 
> 




From bruninga at usna.edu  Wed Feb 27 21:43:45 2008
From: bruninga at usna.edu (Robert Bruninga)
Date: Wed, 27 Feb 2008 16:43:45 -0500
Subject: [htaprs] VC-H1 APRN network
In-Reply-To: <478F6623898BBC4DBD692A223D28298A2598E0@amewebsrvr.webametx.local>
References: <47C4532A.2080902@opentrac.org>	<47C4749F.7010405@opentrac.org><01ed01c878c9$5f2c2f70$42577a83@ewlab.usna.edu><47C493F1.11878.FFB71D@kb2scs.optonline.net>	<C9EF23045BD16A44A7B86F595C41536125E7B8@amewebsrvr.webametx.local><478F6623898BBC4DBD692A223D28298A2598D8@amewebsrvr.webametx.local><47C5783C.4000009@opentrac.org><C9EF23045BD16A44A7B86F595C41536125E7DA@amewebsrvr.webametx.local><478F6623898BBC4DBD692A223D28298A2598DE@amewebsrvr.webametx.local><C9EF23045BD16A44A7B86F595C41536125E7EA@amewebsrvr.webametx.local>
	<478F6623898BBC4DBD692A223D28298A2598E0@amewebsrvr.webametx.local>
Message-ID: <026501c87989$d3c9b030$42577a83@ewlab.usna.edu>

> Then why use APRS-IS at all?  Why not send this, 
> as Scott recommended, directly to the APRN server(s). 

With this recent idea, I do not envision the need for an "APRN
Server", but rather simple local "APRN Nodes".  These nodes
monitor the local SSTV uplink channels and collect images and
save them for recall.  The images may eitehr be recalled over
the air on the same RF network, or, since they are stored and
are connected to the internet, then each local image has a local
URL.

The identification of the picture and the URL to point to it,
then, are the only things injected into the APRS-IS.

> The information does no good on APRS and would 
> require a more complex "IGate" configuration 
> requiring the APRN IGate to connect to both 
> APRS-IS and to the APRN servers.  Keep it
> simple.

Yes, that is why the idea has evolved this way.  That is, do not
re-invent a new server system.  Just use the APRS-IS as the
distribution system for the information (a single packet).  This
lets the APRN "node" be autonomous and hold its own images for
access over the web by anyone with a browser and the URL to the
image held on that machine.

I guess you would call that a "server", since it is serving up
web pages of images, but I am calling it a "node" to distinguish
it from an "APRS server" which is serving real-time packets.  So
in this case, then the APRN node just launches an APRS packet
into the APRS-IS just like anyother user data source.

This keeps it simple by not inventing anything new.  And since
John KB2SCS has already written the APRN node software, it seems
like this approach would be viable.

The APRS-IS does not do anything unusual with these APRN
packets.  But applications, such as FINDU, can then collect the
APRN packets and have pointers to the images on demand.

Something like that....  Oh, and I am abandoning the idea of
having the APRN node append info onto the originators Mic-E
packet.  Lets keep the image uplink identifier packet (usually
Mic-E) separate from the APRN node's packet that it injects into
the APRS-IS.  This avoids any appearance of the APRN-node acting
as an Igate.  It is  not.  It receives an image identification
packet, parses it, stores it, does whatever it needs to do with
it, but then it generates a single packet in an exact format
that it then originated into the APRS-IS.  I have a suggested
format on my web page:

http://web.usna.navy.mil/~bruninga/aprntxt.html

Bob, WB4APR
> 73,
> 
> Pete Loveall AE5PL
> pete at ae5pl dot net
> 
> > -----Original Message-----
> > From: Robert Bruninga
> > Posted At: Wednesday, February 27, 2008 2:57 PM
> > Subject: RE: [htaprs] VC-H1 APRN network
> > 
> > We are not sending an "image packet".  What we would be
sending
> > on the APRS-IS network is a single Mic-E position packet
> > whenever a new image is uploaded to an APRN node.  That
packet
> > is a standard Mic-E packet generated by the handheld D7 HT
with
> > these existing standard fields:
> > 
> > CALL, LAT/LONG/CSE/SPD and STATUS TEXT.  The only thing
unique
> > to this application is that the "status text" contains a URL
> > that points to where the image can be viewed.
> > 
> > It is no different from any other position packet from any
other
> > D7, except for the length of the URL on the end.
> 
> _______________________________________________
> htaprs mailing list
> htaprs at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/htaprs
> 




From bruninga at usna.edu  Wed Feb 27 21:46:29 2008
From: bruninga at usna.edu (Robert Bruninga)
Date: Wed, 27 Feb 2008 16:46:29 -0500
Subject: [htaprs] VC-H1 APRN network
In-Reply-To: <478F6623898BBC4DBD692A223D28298A2598E1@amewebsrvr.webametx.local>
References: <47C4532A.2080902@opentrac.org>	<47C4749F.7010405@opentrac.org><01ed01c878c9$5f2c2f70$42577a83@ewlab.usna.edu><47C493F1.11878.FFB71D@kb2scs.optonline.net>	<C9EF23045BD16A44A7B86F595C41536125E7B8@amewebsrvr.webametx.local><478F6623898BBC4DBD692A223D28298A2598D8@amewebsrvr.webametx.local><47C5783C.4000009@opentrac.org><C9EF23045BD16A44A7B86F595C41536125E7DA@amewebsrvr.webametx.local><478F6623898BBC4DBD692A223D28298A2598DE@amewebsrvr.webametx.local><C9EF23045BD16A44A7B86F595C41536125E7EA@amewebsrvr.webametx.local>
	<478F6623898BBC4DBD692A223D28298A2598E1@amewebsrvr.webametx.local>
Message-ID: <026601c8798a$35dfdb50$42577a83@ewlab.usna.edu>

> Also, the method Scott described would require 
> no knowledge on the part of the sender as to 
> putting a URL in the posit since that would be at
> the APRN servers.  Shorter transmissions.

I agree.   So I have now separated the originator's packet from
the APRN node's packet now.  And the APRN node is not now doing
any "Igateing".  The APRN node now, parses out the relevant
information from the originators packet, stores it all, and then
it generates a new packet to the APRS-IS announcing the image.
This way, we are not trying to "append" as I first suggested,
and can have tighter control over the exact format for the APRN
packet.
http://web.usna.navy.mil/~bruninga/aprntxt.html

Bob

> 73,
> 
> Pete Loveall AE5PL
> pete at ae5pl dot net
> 
> 
> > -----Original Message-----
> > From: AE5PL Lists
> > Sent: Wednesday, February 27, 2008 3:24 PM
> > To: 'TAPR APRS Hot Topics Mailing List'
> > Subject: RE: [htaprs] VC-H1 APRN network
> > 
> > Then why use APRS-IS at all?  Why not send this, as Scott 
> recommended,
> > directly to the APRN server(s).  The information does no 
> good on APRS
> > and would require a more complex "IGate" configuration
requiring the
> > APRN IGate to connect to both APRS-IS and to the APRN
servers.  Keep
> it
> > simple.
> > 
> > 73,
> > 
> > Pete Loveall AE5PL
> > pete at ae5pl dot net
> > 
> > > -----Original Message-----
> > > From: Robert Bruninga
> > > Posted At: Wednesday, February 27, 2008 2:57 PM
> > > Subject: RE: [htaprs] VC-H1 APRN network
> > >
> > > We are not sending an "image packet".  What we would be
sending
> > > on the APRS-IS network is a single Mic-E position packet
> > > whenever a new image is uploaded to an APRN node.  That
packet
> > > is a standard Mic-E packet generated by the handheld D7 HT
with
> > > these existing standard fields:
> > >
> > > CALL, LAT/LONG/CSE/SPD and STATUS TEXT.  The only thing
unique
> > > to this application is that the "status text" contains a
URL
> > > that points to where the image can be viewed.
> > >
> > > It is no different from any other position packet from any
other
> > > D7, except for the length of the URL on the end.
> 
> _______________________________________________
> htaprs mailing list
> htaprs at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/htaprs
> 




From HamLists at ametx.com  Wed Feb 27 21:55:14 2008
From: HamLists at ametx.com (AE5PL Lists)
Date: Wed, 27 Feb 2008 15:55:14 -0600
Subject: [htaprs] VC-H1 APRN network
In-Reply-To: <C9EF23045BD16A44A7B86F595C41536125E7F4@amewebsrvr.webametx.local>
References: <47C4532A.2080902@opentrac.org>	<47C4749F.7010405@opentrac.org><01ed01c878c9$5f2c2f70$42577a83@ewlab.usna.edu><47C493F1.11878.FFB71D@kb2scs.optonline.net>	<C9EF23045BD16A44A7B86F595C41536125E7B8@amewebsrvr.webametx.local><478F6623898BBC4DBD692A223D28298A2598D8@amewebsrvr.webametx.local><47C5783C.4000009@opentrac.org><C9EF23045BD16A44A7B86F595C41536125E7DA@amewebsrvr.webametx.local><478F6623898BBC4DBD692A223D28298A2598DE@amewebsrvr.webametx.local><C9EF23045BD16A44A7B86F595C41536125E7EA@amewebsrvr.webametx.local><478F6623898BBC4DBD692A223D28298A2598E1@amewebsrvr.webametx.local>
	<C9EF23045BD16A44A7B86F595C41536125E7F4@amewebsrvr.webametx.local>
Message-ID: <478F6623898BBC4DBD692A223D28298A2598E3@amewebsrvr.webametx.local>

Individual nodes vs. centralized web server(s).  Most people outside of
the US (and most people inside of the US, for that matter) do not have
the capability to support one of these APRN web servers (call it what it
is, it is not a node).  #1 - no fixed IP.  #2 - no upload bandwidth.  #3
- server operation blocked by ISP.

If you really want to keep it simple, go with Scott's original idea and
stick with it.  You are over-complicating this by not understanding what
most people have access to.  Create a separate APRN network if you want
it to ever get off the ground.  If people have to host their own web
servers, you can basically forget about it ever going very far.  And
there need not be -any- notations on the APRS protocol.

73,

Pete Loveall AE5PL
pete at ae5pl dot net

> -----Original Message-----
> From: Robert Bruninga
> Posted At: Wednesday, February 27, 2008 3:47 PM
> Subject: RE: [htaprs] VC-H1 APRN network
> 
> I agree.   So I have now separated the originator's packet from
> the APRN node's packet now.  And the APRN node is not now doing
> any "Igateing".  The APRN node now, parses out the relevant
> information from the originators packet, stores it all, and then
> it generates a new packet to the APRS-IS announcing the image.
> This way, we are not trying to "append" as I first suggested,
> and can have tighter control over the exact format for the APRN
> packet.
> http://web.usna.navy.mil/~bruninga/aprntxt.html



From bruninga at usna.edu  Wed Feb 27 23:29:18 2008
From: bruninga at usna.edu (Robert Bruninga)
Date: Wed, 27 Feb 2008 18:29:18 -0500
Subject: [htaprs] VC-H1 APRN network
In-Reply-To: <478F6623898BBC4DBD692A223D28298A2598E3@amewebsrvr.webametx.local>
References: <47C4532A.2080902@opentrac.org>	<47C4749F.7010405@opentrac.org><01ed01c878c9$5f2c2f70$42577a83@ewlab.usna.edu><47C493F1.11878.FFB71D@kb2scs.optonline.net>	<C9EF23045BD16A44A7B86F595C41536125E7B8@amewebsrvr.webametx.local><478F6623898BBC4DBD692A223D28298A2598D8@amewebsrvr.webametx.local><47C5783C.4000009@opentrac.org><C9EF23045BD16A44A7B86F595C41536125E7DA@amewebsrvr.webametx.local><478F6623898BBC4DBD692A223D28298A2598DE@amewebsrvr.webametx.local><C9EF23045BD16A44A7B86F595C41536125E7EA@amewebsrvr.webametx.local><478F6623898BBC4DBD692A223D28298A2598E1@amewebsrvr.webametx.local><C9EF23045BD16A44A7B86F595C41536125E7F4@amewebsrvr.webametx.local>
	<478F6623898BBC4DBD692A223D28298A2598E3@amewebsrvr.webametx.local>
Message-ID: <027201c87998$92a70b70$42577a83@ewlab.usna.edu>

> Individual nodes vs. centralized web server(s).  
> Most people... do not have the capability to 
> support one of these APRN web servers...
> ... You are over-complicating this...
> ... Create a separate APRN network if you want
> it to ever get off the ground.

Some good points.

The beauty of my proposal is that the APRN "serving" function is
independent of the APRS packet distribution.  If people want
their images to be hosted on a personal, or  local, or regional
or global APRN "server", that is independent and can be
determined by whoever writes the code for a particular APRN
node.

But the packet distribution should remain on the APRS-IS.  There
is no reason to re-invent that wheel.  The packet contains the
URL to wherever the image is hosted.  By keeping the two
functions separate and independent best follows the KISS
principal.

> And there need not be -any- notations on the APRS protocol.

Agreed.  There is no change to the APRS protocol.  Just a
notation on how the information in the existing fields of an
object packet using the SSTV symbol can be interpreted in a
consistent manner.  

So, to clarify the evolving definitions then:

APRN Node - The code that listens on specialized APRN local RF
channels for SSTV images and associated APRS "label" packets.
The APRN node places these images on an APRN "server" where the
images can be downloaded by URL.  The APRN node originates a
formatted SSTV object packet into the APRS-IS announcing this
image and URL.

APRN Server - a server that makes these images available on the
web by URL

APRS-IS - As previously defined with no changes.

Note:  The APRN node can serve the images back to local SSTV RF
as appropriate locally depending on the RF hardware...

Hope that nails it.
Bob, WB4APR


> 73,
> 
> Pete Loveall AE5PL
> pete at ae5pl dot net
> 
> > -----Original Message-----
> > From: Robert Bruninga
> > Posted At: Wednesday, February 27, 2008 3:47 PM
> > Subject: RE: [htaprs] VC-H1 APRN network
> > 
> > I agree.   So I have now separated the originator's packet
from
> > the APRN node's packet now.  And the APRN node is not now
doing
> > any "Igateing".  The APRN node now, parses out the relevant
> > information from the originators packet, stores it all, and
then
> > it generates a new packet to the APRS-IS announcing the
image.
> > This way, we are not trying to "append" as I first
suggested,
> > and can have tighter control over the exact format for the
APRN
> > packet.
> > http://web.usna.navy.mil/~bruninga/aprntxt.html
> 
> _______________________________________________
> htaprs mailing list
> htaprs at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/htaprs
> 




From kb2scs at optonline.net  Thu Feb 28 00:16:54 2008
From: kb2scs at optonline.net (kb2scs at optonline.net)
Date: Wed, 27 Feb 2008 19:16:54 -0500
Subject: [htaprs] VC-H1 APRN network
In-Reply-To: <027201c87998$92a70b70$42577a83@ewlab.usna.edu>
References: <47C4532A.2080902@opentrac.org>
	<478F6623898BBC4DBD692A223D28298A2598E3@amewebsrvr.webametx.local>
	<027201c87998$92a70b70$42577a83@ewlab.usna.edu>
Message-ID: <47C5B726.22545.464620@kb2scs.optonline.net>

Hi All
         Before we go any further here is how my APRN software works.
Note the software follows the original APRN concept.

The user starts the APRN Software
He then starts his APRS client software
He then starts his SSTV software.

His APRS software is full screen on his PC screen. The map is zoomed 
into the area where he expects to receive SSTV images from.

This is all done on a frequency other than 144.390

The user out in the field taking the pictures has an APRS packet sent 
at the end of his SSTV transmission.

The APRN software detects that the sstv program has received a new 
image. So the last APRS packet received goes with this new SSTV image.

A screen shot of the PC screen is taken.
A new HTML file is created. 

The new HTML file along with the PC screen shot along with the SSTV 
image are all sent to the web page of the APRN user via ftp.

Now when a person via his web browser goes to the web page they do not 
see the images . what they do see is a bunch of hyper links. One 
hyperlink per each screen shot and SStv image. The web user then clicks 
on a hyper link then another web page opens showing the screen shot of 
the APRS Map and the SSTV image.

So no servers are used other than the users own web space. 

In other words to use APRN the user has to have ftp access to a web 
site.

Hope this did not confuse any one.

Let us hope we never witness the "Silence Of The Hams"
73 DE John  KB2SCS
       E-Mail:            kb2scs at arrl.net
       APRS-SCS     http://www.tapr.org/~kb2scs
       Web Page:     http://www.qsl.net/kb2scs



From n7yge at hctc.com  Thu Feb 28 00:25:16 2008
From: n7yge at hctc.com (Jerry N7YGE)
Date: Wed, 27 Feb 2008 16:25:16 -0800
Subject: [htaprs] VC-H1
In-Reply-To: <47C4C633.70700@opentrac.org>
Message-ID: <008201c879a0$64f5d5a0$8307a8c0@JERRY>

Scott,

On the packaging issue.  Have you considered using a 3D printer which can
make a plastic part?  I have a 3D CAD program where I can build the part and
assembly, put it into a file format the 3D printer uses, send it to the
printer, and out comes the part(s).  A college near you might have a 3D
printer and let you play in order to complete a prototype.  

I know there are businesses out there now with the 3D printers that sell
their services.  I have never looked into what the cost per unit would be.
But it might be worth a shot.  I can help you make the 3D file if you can
send me the dimensions of what you want build.  Throw the design on a
napkin, scan it, and send me the file.  We can adjust things as it evolves.
We could make block envelopes for each piece that will go inside the casing
pieces.


Also I keep wondering if a ODS board might work in some manner for your
project.   I use and ODS board to place the GPS and call sign information on
top of the fast scan pictures (overlay).

Jerry N7YGE

**************************************

-----Original Message-----
From: htaprs-bounces at lists.tapr.org [mailto:htaprs-bounces at lists.tapr.org]
On Behalf Of Scott Miller
Sent: Tuesday, February 26, 2008 6:09 PM
To: TAPR APRS Hot Topics Mailing List
Subject: Re: [htaprs] VC-H1


Trouble is I have very specific constraints for the camera, and I can't 
handle NTSC with this version.  The camera is a CMOS imager with an 
integrated JPEG processor, which also happens to output uncompressed 
RGB.  The serial interface lets me use cheap, slow memory.  If I could 
get it to send data in chunks like it does with JPEGs, I wouldn't even 
need any external memory at all.

For my next version, I'm planning to handle an 8-bit parallel BT.656 
interface with fast SRAM.  That'll mean spending about 4 times as much 
on memory (for 1/4 the capacity) and it'll occupy a lot more board space 
and I/O pins, but it also means that I can use an off-the-shelf 
NTSC/PAL/SECAM processor OR a typical cell phone type digital camera.

That version will also very likely have a 32-bit processor - it'll be 
worth the extra $4-7 for the stress and hair loss it'll prevent on my 
part.  I'm currently using an 8-bit chip at 14.7 MHz, and I'd be 
surprised if anyone has ever done real-time SSTV encoding with an 8-bit 
chip before.  I've got it working well in S1 mode, but I have some 
doubts about being able to get it to do Robot 36 - not only does it need 
to get data from the camera faster, but it also has to do RGB to YCbCr 
with chroma subsampling on the fly.

Assuming S1 mode (and maybe S2) is good enough, my problem is now 
packaging - what enclosure am I going to put the whole thing in, how do 
I mount the camera, what buttons will it have, where will they go, and 
where do the cables go?  I want to make a hand-held, battery-powered 
unit that could work with an HT.  Running the radio cable out the bottom 
is the most ergonomic choice there, but for most case designs you have 
interference with the battery compartment.  Injection molded plastic 
cases generally have sloping sides to facilitate ejection from the mold, 
so those are a pain to mount connectors in.

I'm considering putting the camera in a separate enclosure, and setting 
it up so it could be either mated directly with the encoder or remoted 
using a common cable.  It doesn't need to swivel like the VC-H1 (no 
need, with no screen) so a DB9 would probably work.  I could add an 
RS-232 transceiver on both ends to increase the maximum cable length, 
but I'm not sure it'd be worth the added complexity.

I think the next version with the NTSC/PAL interface will be in an 
extruded aluminum enclosure, and it'll certainly have RCA jacks and 
possibly S-video as well.  I can see the value of having a 
battery-powered version, though - you could clip it to your belt and 
plug a camcorder in to it, and just hit the 'send' button every time you 
want to send a still.

Scott
N1VG

Jerry N7YGE wrote:
> I have used this company for my fast scan ATV work for years.
> http://www.supercircuits.com/index.asp
> 
> They have an excellent assortment of cameras.  You might want to 
> contact them as to your specific needs.
> 
> If you are building a new black box, you might think about making it 
> with RCA jacks so you can change out the camera easily.  You might 
> want a Infa Red (IR) camera at times for night work.
> 
> Sounds like a fun project you have going.
> 
> Jerry N7YGE
> 
> 
> -----Original Message-----
> From: htaprs-bounces at lists.tapr.org 
> [mailto:htaprs-bounces at lists.tapr.org]
> On Behalf Of Scott Miller
> Sent: Tuesday, February 26, 2008 11:33 AM
> To: TAPR APRS Hot Topics Mailing List
> Subject: Re: [htaprs] VC-H1
> 
> 
> Well, seeing as I can't find any other VC-H1 group, or even any active
> SSTV group aside from MM-SSTV, I guess I'll ask this here.
> 
> My new project is up and running - it's a standalone SSTV encoder with
> camera.  Sort of like a transmit-only VC-H1, but it'll have more 
> automation and remote control features.  It's also got a character 
> generator that'll display 40 characters of text in the top 16 lines, and 
> I may add a parser for GPS data and I'll definitely allow arbitrary text 
> to be entered through a serial port for telemetry and such.
> 
> I'm not thrilled with the camera module, but it was reasonably easy to
> interface.  If I'm going to stick with this camera, the big question is 
> which lens to use.  There's at least some possibility to allow the user 
> to select a lens, but the mechanical design will limit the lens choice.
> 
> I'm currently using a 109 degree wide-angle lens.  It captures a lot 
> of
> the scene, but it's hard to get much detail unless you're really close, 
> and that introduces focus problems.  Anyone have any suggestions on what 
> would be an appropriate FOV?
> 
> Also, any other deficiencies in the VC-H1 that I should try to avoid
> duplicating?
> 
> If I can get the transmitter to survive the high duty cycle, I'm going
> to try pairing one of my prototypes with an MX146 transmitter and see 
> how small and light I can make a SSTV-capable high-altitude balloon
payload.
> 
> I'll at least have a demo running at Dayton, and maybe even the first
> batch of production units, but I'm not making any promises yet.
> 
> Scott
> N1VG
> 
> VA7OTC JD Erskine wrote:
>> Scott Miller wrote:
>>> Is this list still active?  I can't find any archives.  And is 
>>> discussion of the VC-H1 still on-topic?
>>>
>>> Scott
>>> N1VG
>> 
>> Appears to  be. I tried a search for VC-H1 on the TAPR site and 
>> didn't find much.
>> 
>> 73 John/'JD'
>> VA7OTC VE0JD/mm
>> 
>> ---
>> 
>> 
>>     * To: "TAPR AO-16 APRS Special Interest Group" 
>> <ao16aprs at lists.tapr.org>
>>     * Subject: [ao16aprs] HTAPRS expanded for VC H1
>>     * From: "Horzepa, Stan" <Stan_Horzepa at adc.com>
>>     * Date: Mon, 15 Feb 1999 14:38:30 -0600
>>     * List-Owner: <mailto:owner-ao16aprs at lists.tapr.org>
>>     * List-Software: Lyris Server version 3.0
>>     * List-Subscribe: <mailto:subscribe-ao16aprs at lists.tapr.org>
>>     * List-Unsubscribe: <mailto:leave-ao16aprs-833L at lists.tapr.org>
>> 
>> The purpose of the TAPR HTAPRS SIG has been expanded to include 
>> discussion of Kenwood's VC H1 (KenCam) and related issues, such as 
>> the Automatic Picture Relay Network (APRN). So, talk among yourselves 
>> about VC H1 on HTAPRS.
>> 
>> Stan, WA1LOU, *SIG administrator
>> 
>> _______________________________________________
>> htaprs mailing list
>> htaprs at lists.tapr.org
>> https://lists.tapr.org/cgi-bin/mailman/listinfo/htaprs
>> 
>> 
> 
> 
> _______________________________________________
> htaprs mailing list
> htaprs at lists.tapr.org 
> https://lists.tapr.org/cgi-bin/mailman/listinfo/htaprs
> 
> 
> 
> _______________________________________________
> htaprs mailing list
> htaprs at lists.tapr.org 
> https://lists.tapr.org/cgi-bin/mailman/listinfo/htaprs
> 
> 


_______________________________________________
htaprs mailing list
htaprs at lists.tapr.org https://lists.tapr.org/cgi-bin/mailman/listinfo/htaprs





From scott at opentrac.org  Thu Feb 28 05:15:54 2008
From: scott at opentrac.org (Scott Miller)
Date: Wed, 27 Feb 2008 21:15:54 -0800
Subject: [htaprs] VC-H1
In-Reply-To: <008201c879a0$64f5d5a0$8307a8c0@JERRY>
References: <008201c879a0$64f5d5a0$8307a8c0@JERRY>
Message-ID: <47C6438A.50005@opentrac.org>

> On the packaging issue.  Have you considered using a 3D printer which can
> make a plastic part?  I have a 3D CAD program where I can build the part and

I'd love to have one of those.  I know of a couple around here, but 
they're owned by the Air Force.  They're also pretty expensive to 
operate - the housing would probably cost me more than everything else 
by a wide margin.  I don't think I can afford injection molding either, 
not for the volumes I'm looking at.  Someday I'll be able to do that, I 
hope.

For now, I've got to either work with customized off-the-shelf 
enclosures (injection molded plastic, extruded aluminum, etc) or I can 
get fully custom aluminum or steel cases - those tend to be more 
suitable for desktop and industrial applications than handheld 
electronics, though.

Most likely, I'll be working with cases from Hammond or Pactec and 
having them customized with CNC machining.

> Also I keep wondering if a ODS board might work in some manner for your
> project.   I use and ODS board to place the GPS and call sign information on
> top of the fast scan pictures (overlay).

If you're talking about an on-screen display, there's no need for a 
separate chip.  I'm already doing that in the first 16 lines of the 
image.  I could overlay text on the image itself, but it'd take a little 
more processing time.  For now it's got 40 columns of text (8x12 format) 
to display callsign, GPS, or telemetry data.

Scott
N1VG




From bruninga at usna.edu  Thu Feb 28 16:30:35 2008
From: bruninga at usna.edu (Robert Bruninga)
Date: Thu, 28 Feb 2008 11:30:35 -0500
Subject: [htaprs] VC-H1
In-Reply-To: <47C6438A.50005@opentrac.org>
References: <008201c879a0$64f5d5a0$8307a8c0@JERRY>
	<47C6438A.50005@opentrac.org>
Message-ID: <02c501c87a27$3edca560$42577a83@ewlab.usna.edu>

> If you're talking about an on-screen display, ...
> I'm already doing that in the first 16 lines 
> of the image....  For now it's got 40 columns 
> of text (8x12 format) to display callsign, 
> GPS, or telemetry data.

I'm glad to hear this is similar to the VC-H1 in function.  If
your product can re-vitalize the handi-cam concept, then we
would hope that the APRN system will be compatible with both
your product and all those VC-H1's that will come out of the
closet and want to play too..

So maintaining some backwards compatibility to the VC-H1 concept
I think is a good idea.

Thanks
Bob, WB4APR




From scott at opentrac.org  Thu Feb 28 16:36:39 2008
From: scott at opentrac.org (Scott Miller)
Date: Thu, 28 Feb 2008 08:36:39 -0800
Subject: [htaprs] VC-H1
In-Reply-To: <02c501c87a27$3edca560$42577a83@ewlab.usna.edu>
References: <008201c879a0$64f5d5a0$8307a8c0@JERRY>	<47C6438A.50005@opentrac.org>
	<02c501c87a27$3edca560$42577a83@ewlab.usna.edu>
Message-ID: <47C6E317.1010403@opentrac.org>

I've never actually used a VC-H1 myself, but I've read about their 
quirks.  I was worried about the lack of a mechanism to see what you're 
taking a picture of, but apparently the VC-H1 didn't let you do that either.

I know the camera was removable - was it easy to remote, like if you 
wanted to put it on your dashboard, separate from the rest of the unit?

Scott
N1VG

Robert Bruninga wrote:
>> If you're talking about an on-screen display, ...
>> I'm already doing that in the first 16 lines 
>> of the image....  For now it's got 40 columns 
>> of text (8x12 format) to display callsign, 
>> GPS, or telemetry data.
> 
> I'm glad to hear this is similar to the VC-H1 in function.  If
> your product can re-vitalize the handi-cam concept, then we
> would hope that the APRN system will be compatible with both
> your product and all those VC-H1's that will come out of the
> closet and want to play too..
> 
> So maintaining some backwards compatibility to the VC-H1 concept
> I think is a good idea.
> 
> Thanks
> Bob, WB4APR
> 
> 
> _______________________________________________
> htaprs mailing list
> htaprs at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/htaprs
> 
> 




From fkf1 at cornell.edu  Thu Feb 28 17:26:47 2008
From: fkf1 at cornell.edu (F. Kevin Feeney)
Date: Thu, 28 Feb 2008 12:26:47 -0500
Subject: [htaprs] VC-H1
In-Reply-To: <47C6E317.1010403@opentrac.org>
References: <008201c879a0$64f5d5a0$8307a8c0@JERRY>	<47C6438A.50005@opentrac.org>	<02c501c87a27$3edca560$42577a83@ewlab.usna.edu>
	<47C6E317.1010403@opentrac.org>
Message-ID: <47C6EED7.9000901@cornell.edu>

Scott Miller wrote:
> I've never actually used a VC-H1 myself, but I've read about their quirks.
They definitely are quirky. Handy though.
>   I was worried about the lack of a mechanism to see what you're 
> taking a picture of, but apparently the VC-H1 didn't let you do that 
> either.
Actually, it does. You can press the button on the side and get a 
realtime view of the camera's output on the screen. Press the button 
again and it captures it to temporary  memory for sending.
>
> I know the camera was removable - was it easy to remote, like if you 
> wanted to put it on your dashboard, separate from the rest of the unit?
It plugs in with a 3.5 mm stereo plug, so I suppose an extender cord 
with a suitable jack and plug such as used for audio extensions would 
work, though I haven't tried that. The stock camera seems to be 
optimized for shooting head and shoulders shots of nearby folks. It's 
not very good at showing things more distant from the camera such as 
storm damage or area views. For public service events, I usually plug my 
digital camera into the unit using the NTSC output of the digicam, 
normally used to play pictures out to a tv monitor, to feed the VC-H1. 
That allows me to use the better optics of a real camera, including a 
good zoom lens for framing the shots. I can either grab the image using 
the VC-H1's memory, or more often I shoot the image on the digicam, and 
then send it later from the digicam's review function. That allows me to 
shoot multiple pics as the event is happening, then send them shortly 
afterwards when I have time to pay attention to shot selection and 
choosing which images are suitable for sending.

To tell the truth, I very rarely use the VC-H1's stock camera. I'm much 
more interested in a device that allows me to use the output of other 
digital cameras and video devices I have on hand - generally having NTSC 
outputs. Their optics are always vastly superior and more flexible, and 
often I am using them as part of my documentation process of the event 
anyhow. It's hard to pick a small, inexpensive, camera for dedicated use 
that has the flexibility to meet the various needs of SSTV users, 
particularly for public service events.

One use I put mine to is to take the feed from the nose camera on my 
ultralight airplane and do an automated picture grab every 3 minutes, or 
when I force a grab,  and send it. I use it with my D7 so every 3 
minutes the system transmits a view of what the airplane is seeing, and 
then the D7 stamps it with a trailing APRS packet with time and 
coordinates, altitude and speed. (I do this on a non-APRS frequency for 
obvious reasons. Usually a local simplex frequency where friends are 
monitoring.) I'd love to have a system that gave me more flexibility to 
set up systems of this type.

73 de Kevin, WB2EMS

>
> Scott
> N1VG





From bruninga at usna.edu  Thu Feb 28 20:26:12 2008
From: bruninga at usna.edu (Robert Bruninga)
Date: Thu, 28 Feb 2008 15:26:12 -0500
Subject: [htaprs] VC-H1 features
In-Reply-To: <47C6EED7.9000901@cornell.edu>
References: <008201c879a0$64f5d5a0$8307a8c0@JERRY>	<47C6438A.50005@opentrac.org>	<02c501c87a27$3edca560$42577a83@ewlab.usna.edu><47C6E317.1010403@opentrac.org>
	<47C6EED7.9000901@cornell.edu>
Message-ID: <02ea01c87a48$29428b40$42577a83@ewlab.usna.edu>

> I was worried about the lack of a mechanism 
> to see what you're taking a picture of, but 
> apparently the VC-H1 didn't let you do that 
> either.

The VC-H1 was an amazing device.  Kenwood never put in the ads
all it could do.

1) The camera is full motion NTSC standard video
2) It has a 1vpp video output for any FSTV ATV transmitter
3) It has a 1vpp video input for use with any external camera
4) It has a full video standard NTSC video display
5) It could be used as an FSTV ATV receiver display
6) It has built-in Video to JPEG capture
7) It has bulit-in JPG or NTSC to SSTV converter
8) It has built-in SSTV to NTSC video outputs.
9) It has inputs and outputs for all of these formats
10) It is plug-and-play with most Kenwood HT's...
11) The D7 could even use its keypad for entering and overlaying
text on each image for TX.

In other words, it was a full Fast Scan normal NTSC video device
AND SSTV device all in one.  Kenwood never mentioned the NTSC
and Fast scan TV because they feared people would think it had
an ATV "transmitter" and "receiver"... And be confused.

> I know the camera was removable,

Yes, just a 3 wire standard Phone plug and jack..

Bob, Wb4APR




From kb4oid at kb4oid.org  Thu Feb 28 20:31:16 2008
From: kb4oid at kb4oid.org (Steve McCarter)
Date: Thu, 28 Feb 2008 14:31:16 -0600
Subject: [htaprs] VC-H1
In-Reply-To: <47C6438A.50005@opentrac.org>
References: <008201c879a0$64f5d5a0$8307a8c0@JERRY>
	<47C6438A.50005@opentrac.org>
Message-ID: <20a601c87a48$dec14060$b100a8c0@uriel>

You might want to check out these guys: <http://pei2000.com/>

The company I work for has used them in the past to build some oddly shaped
plastic enclosures with milled cutouts and internal bosses in weird places.
I believe they build up the enclosures out of plastic sheet by ultrasonic or
chemical welding. Can't speak to price on low volume, as the units we
purchased were hundred's quantities...~Steve>

Steve McCarter, KB4OID
Email: kb4oid at kb4oid.org 
Website: http://www.kb4oid.org 
Fort Walton Beach, FL, 32547 

> -----Original Message-----
> From: htaprs-bounces at lists.tapr.org [mailto:htaprs-bounces at lists.tapr.org]
> On Behalf Of Scott Miller
> Sent: Wednesday, February 27, 2008 11:16 PM
> To: TAPR APRS Hot Topics Mailing List
> Subject: Re: [htaprs] VC-H1
> 
> > On the packaging issue.  Have you considered using a 3D printer which
> can
> > make a plastic part?  I have a 3D CAD program where I can build the part
> and
> 
> I'd love to have one of those.  I know of a couple around here, but
> they're owned by the Air Force.  They're also pretty expensive to
> operate - the housing would probably cost me more than everything else
> by a wide margin.  I don't think I can afford injection molding either,
> not for the volumes I'm looking at.  Someday I'll be able to do that, I
> hope.
> 
> For now, I've got to either work with customized off-the-shelf
> enclosures (injection molded plastic, extruded aluminum, etc) or I can
> get fully custom aluminum or steel cases - those tend to be more
> suitable for desktop and industrial applications than handheld
> electronics, though.
> 
> Most likely, I'll be working with cases from Hammond or Pactec and
> having them customized with CNC machining.
> 
> > Also I keep wondering if a ODS board might work in some manner for your
> > project.   I use and ODS board to place the GPS and call sign
> information on
> > top of the fast scan pictures (overlay).
> 
> If you're talking about an on-screen display, there's no need for a
> separate chip.  I'm already doing that in the first 16 lines of the
> image.  I could overlay text on the image itself, but it'd take a little
> more processing time.  For now it's got 40 columns of text (8x12 format)
> to display callsign, GPS, or telemetry data.
> 
> Scott
> N1VG
> 
> 
> _______________________________________________
> htaprs mailing list
> htaprs at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/htaprs




From scott at opentrac.org  Thu Feb 28 21:06:07 2008
From: scott at opentrac.org (Scott Miller)
Date: Thu, 28 Feb 2008 13:06:07 -0800
Subject: [htaprs] VC-H1
In-Reply-To: <20a601c87a48$dec14060$b100a8c0@uriel>
References: <008201c879a0$64f5d5a0$8307a8c0@JERRY>	<47C6438A.50005@opentrac.org>
	<20a601c87a48$dec14060$b100a8c0@uriel>
Message-ID: <47C7223F.2030806@opentrac.org>

> The company I work for has used them in the past to build some oddly shaped
> plastic enclosures with milled cutouts and internal bosses in weird places.
> I believe they build up the enclosures out of plastic sheet by ultrasonic or
> chemical welding. Can't speak to price on low volume, as the units we
> purchased were hundred's quantities...~Steve>

Thanks, looks like it's worth checking out at least.  I'm thinking about 
an initial run of 100-200 units, so it's not REALLY small quantities.

Scott
N1VG




From sv1uy at sz8l.gr  Fri Feb 29 06:31:42 2008
From: sv1uy at sz8l.gr (Demetre Valaris)
Date: Fri, 29 Feb 2008 08:31:42 +0200 (EET)
Subject: [htaprs] Re: VC-H1
In-Reply-To: <E1JUn3F-0005kg-O1@giskard.tapr.org>
References: <E1JUn3F-0005kg-O1@giskard.tapr.org>
Message-ID: <56035.195.78.86.91.1204266702.squirrel@www.sz8l.gr>

> Date: Thu, 28 Feb 2008 08:36:39 -0800
> From: Scott Miller <scott at opentrac.org>
> Subject: Re: [htaprs] VC-H1
> I've never actually used a VC-H1 myself, but I've read about their
> quirks.  I was worried about the lack of a mechanism to see what you're
> taking a picture of, but apparently the VC-H1 didn't let you do that
> either.
>
> I know the camera was removable - was it easy to remote, like if you
> wanted to put it on your dashboard, separate from the rest of the unit?
>
> Scott
> N1VG

Hi Scott and group,

If I understand well you are saying that you cannot monitor what you are
shooting with th VC-H1. I have 2 of those cameras and I can see what
pictures I am taking. The most serious problem with them is that you
cannot change the default SSTV mode from ROBOT to anything else unless you
receive a picture in another mode first, but really even this is hardly a
problem since all SSTV computer programs can receive ROBOT 36 seconds
pictures. OK the resolution of the camera is not great but SSTV pictures
do not have to be great either.

I have successfully played with APRN in the past (a few years back) but
people were not so interested in APRS then so I stopped. Now that I see
that there is some interest I will try to install a dedicated APRN server
here in Athens, especially after the increased earthquake activity we have
been having during the past month.

Nice toy this APRN.

---
73 de Demetre Valaris - SV1UY
e-mail sv1uy at sz8l.gr




From scott at opentrac.org  Fri Feb 29 05:35:21 2008
From: scott at opentrac.org (Scott Miller)
Date: Thu, 28 Feb 2008 21:35:21 -0800
Subject: [htaprs] Re: VC-H1
In-Reply-To: <56035.195.78.86.91.1204266702.squirrel@www.sz8l.gr>
References: <E1JUn3F-0005kg-O1@giskard.tapr.org>
	<56035.195.78.86.91.1204266702.squirrel@www.sz8l.gr>
Message-ID: <47C79999.4050402@opentrac.org>

> shooting with th VC-H1. I have 2 of those cameras and I can see what
> pictures I am taking. The most serious problem with them is that you

Ok, the description I read was wrong then.

> cannot change the default SSTV mode from ROBOT to anything else unless you
> receive a picture in another mode first, but really even this is hardly a
> problem since all SSTV computer programs can receive ROBOT 36 seconds
> pictures. OK the resolution of the camera is not great but SSTV pictures
> do not have to be great either.

That does seem like an odd misfeature.

I found a fairly new ARM7-based chip from NXP today that I think I like 
better than the Atmel part I'd been planning to use for my next project. 
  If I go with that, it'll have a lot more processing power to handle 
image processing.  Alas, it still won't have enough internal RAM for 
frame buffer, but it's still 48 times more RAM than I have now!

I see they've got 320x240 OLED displays out now - I wonder how much 
they're going for.  And I wonder how long it'll be before you can get 
membrane keypads integrated with them... it'd certainly simplify the 
mechanical design.

Scott
N1VG




From scott at opentrac.org  Fri Feb 29 20:40:06 2008
From: scott at opentrac.org (Scott Miller)
Date: Fri, 29 Feb 2008 12:40:06 -0800
Subject: [htaprs] VC-H1
In-Reply-To: <47C6EED7.9000901@cornell.edu>
References: <008201c879a0$64f5d5a0$8307a8c0@JERRY>	<47C6438A.50005@opentrac.org>	<02c501c87a27$3edca560$42577a83@ewlab.usna.edu>	<47C6E317.1010403@opentrac.org>
	<47C6EED7.9000901@cornell.edu>
Message-ID: <47C86DA6.5080408@opentrac.org>

> To tell the truth, I very rarely use the VC-H1's stock camera. I'm much 
> more interested in a device that allows me to use the output of other 
> digital cameras and video devices I have on hand - generally having NTSC 
> outputs. Their optics are always vastly superior and more flexible, and 
> often I am using them as part of my documentation process of the event 
> anyhow. It's hard to pick a small, inexpensive, camera for dedicated use 
> that has the flexibility to meet the various needs of SSTV users, 
> particularly for public service events.

That's very true, but I can also make a system with a low-speed digital 
camera with a lot fewer parts and for a lower cost than an NTSC capture 
system.  I'm going to try out all of the available lens options, and see 
about mounting the camera separately.  I think it'll still be great for 
balloon experiments and such.

> monitoring.) I'd love to have a system that gave me more flexibility to 
> set up systems of this type.

I got some samples of the video decoder chips in.  Gotta remember to 
pick up some prototyping adapters for LQFP32 packages.  I could build a 
system using the same processor I'm using now, but I'm really not sure I 
want to.  Maybe I'll go ahead and implement Robot 36 and see how bad the 
RGB <> YCbCr conversion is.  I've also got to fire up this CPLD demo 
board and figure out how I'm going to do the glue logic for the BT.656 
frame buffer.

Hmmm.. I wonder if it'd be worth adding the video capture hardware to my 
  upcoming multi-mode TNC.  Maybe as a plug-in board, I suppose.  Now 
there's an idea... gotta give the thing a couple of plug-in module 
slots.  Now all I need is another 60 hours in the week..

Scott
N1VG