Random thoughts...

[Colin McGregor]

This past week I have been noting ideas that strike me as potentially
interesting projects for a hams during crisis group, and additions to
this list list would be welcome:

Information Collection / Wiki Projects:

- License Authorities Worldwide, ie:
- Canada - Industry Canada - www.ic.gc.ca
- USA - Federal Communications Commission - www.fcc.gov

- "National" Amateur Radio Clubs, ie:
- Canada - Radio Amateurs of Canada - www.rac.ca
- USA - Amateur Radio Relay League - www.arrl.org

- Links to periodically updated useful data, ie:
- Amateur spacecraft orbital elements -
http://www.amsat.org/amsat-new/tools/keps.php
- Sunspot activity - http://dx.qsl.net/propagation/

- Major hardware vendors, ie: Kenwood, ICOM, etc...

Software projects:

- Suhana Replicator
- Live Linux CD/USB memory key with useful software, ie:
- OSM editor(s), ie: JOSM, Mercator
- Suhana
- Microsat ground station
- Ushihiti
- Poor Mans Packet

Hardware Projects:

- Inexpensive BASIC (2 meter?) transceivers
- Emergency power systems

Hardware/Software projects:

- Store/Forward mailbox system (ie: an updated, USB friendly KPC-3)
- Poor Mans Packet modems.

Yesterday I was out to Radioworld (http://www.radioworld.ca/) had a
look at the neat toys for sale and I picked up a copy of of the 2011
ARRL Handbook (all over 1400 pages of it), and well, I have some
reading to do over the next while...

[Colin McGregor]

Let me toss another $0.02 into all of this, regarding Poor Mans
Packet, this was a very inexpensive packet radio modem that did a lot
of stuff in software to keep costs down. Key problem with the Poor
Mans Packet designs I've seen is that they depend on parallel and/or
serial ports to support them. Parallel and serial ports are DEAD in
the laptop market, and doing a death spiral in the desktop market. So,
an INEXPENSIVE USB based packet modem seems to be needed...

There is the saying, if your only tool is a hammer then all problems
look like nails. Well, at the moment the cheap (but often effective)
hammer in the micro-controller area is the Arduino
(http://en.wikipedia.org/wiki/Arduino). Basically you can get a
firmware development hardware environment for under $30, with free
software development tools available for Linux, Macintosh and MS
Windows. I would like to see how the Arduino could be applied to Poor
Mans Packet (and the packet repeater project...)...

Colin - VE3ZAA

[Aaron Huslage]

You can turn an Arduino into a cheap modem and, with the right shield, a sound card. I see no reason we couldn't use that. 

But if you need a computer anyway, why not just hook up the radio to the computer's sound card? Many radio manufacturers sell radios that are APRS-enabled out of the box with everything integrated...I used to have both of the Kenwood models...and they work great. Converting USB-Serial is more or less trivial at this point, too.   

--
Aaron Huslage
http://blog.hact.net
IM: AIM - ahuslage; Yahoo - ahuslage; MSN - hus...@gmail.com; GTalk - hus...@gmail.com; Skype - huslage

[Colin McGregor]

On Mon, Jun 13, 2011 at 2:17 PM, Aaron Huslage <hus...@gmail.com> wrote:
> You can turn an Arduino into a cheap modem and, with the right shield, a
> sound card. I see no reason we couldn't use that.
> But if you need a computer anyway, why not just hook up the radio to the
> computer's sound card? Many radio manufacturers sell radios that are
> APRS-enabled out of the box with everything integrated...I used to have both
> of the Kenwood models...and they work great. Converting USB-Serial is more
> or less trivial at this point, too.

Yes, well, radios like mine (from the early 1990s) don't have these
features, so any old / primitive radio needs the tones generated
externally. Further, while I don't doubt some clever programming could
send/receive the tones required for 1200 BPS packet off a sound card
that does leave the issue of manipulating the PTT (push to talk)
button. Dealing with the PTT was easy with parallel or serial ports,
but when it seems your only IO port is USB... well, things get a
little messy...

Colin.

[Bernie Roche]

On Mon, Jun 13, 2011 at 6:11 PM, Colin McGregor <colin...@gmail.com> wrote:

[snip]

Dear Colin:

I'm a little confused...what is it that we want to do (from our RHoK weekend) that isn't already available in Ushahidi using Swift River and Crowdmap?

Sorry, I know this is probably a newbie question, but when it comes to some of this stuff, I AM a newbie <grin>.

Also, I remember someone at RHoK asking for used modems.  Was that you, and did anyone else want one?

Best Wishes,

Bernie Roche

VE3OTR

Emergency Coordinator

York Region EmComm

(416) 519-3989 res

(416) 435-0423 cell

VE3...@GMAIL.COM

 

Communicare, Resolvere, Perficere

We Communicate, We Complete, WE GET THINGS DONE

[Aaron Huslage]

From what I understand. The team wanted to create a bridge between APRS and Ushahidi. Vivek wrote some demo code for syncing two Ushahidi instances, but this had no inherent awareness of the underlying protocol. 

We need to make a plugin that speaks APRS using existing open source tools. 

Colin has been focusing on a sort of reference architecture for the hardware side of things. 

--

Aaron Huslage

sent via mobile device

[Vivek Lakshmanan]

Hi All,
Sorry for dropping off for a bit. Aaron is correct. The initial idea
was to allow ushahidi instances to synchronize and update each other
by using an APRS network as a data plane. The prototype of course was
a very crude generalization of this. There will be a few challenges on
the software side going forward as we start learning more about the
idiosyncrasies of APRS. The biggest stumbling block at the moment
though is the lack of packet radio access, especially for people like
me who are not certified HAM radio operators but would like to
contribute. Having a little test packet radio network test-bed would
be extremely useful. Colin's efforts in identifying how to get packet
radio working on existing radios will be pretty helpful going forward
but that can be done independently from getting the project
bootstrapped. Any thoughts on how such a testbed can be setup?
- Vivek

[Colin McGregor]

On Tue, Jun 14, 2011 at 5:12 AM, Aaron Huslage <hus...@gmail.com> wrote:

> From what I understand. The team wanted to create a bridge between APRS and
> Ushahidi. Vivek wrote some demo code for syncing two Ushahidi instances, but
> this had no inherent awareness of the underlying protocol.
> We need to make a plugin that speaks APRS using existing open source tools.
> Colin has been focusing on a sort of reference architecture for the hardware
> side of things.

I guess the questions I am trying to ask are:

- "In a crisis, how do we make the hams in the crisis area more effective?"
- "How do we do a better job of getting information collected by hams
to the outside world?"

The first question can be partially answered with inexpensive, simple,
easily deployed, robust hardware, along with some software. The second
question is largely a software question. Both of these questions need
to be answered.

As in it is all well and good to have a great ham to Ushahidi gateway,
but if you have a ham in the middle of the crisis area and all her
radio equipment was destroyed at the start of the crisis, well ...
until she gets more equipment she is useless from a communications
standpoint...

So, gentlewomen and gentlemen we have a cooked elephant before us. How
do you eat an elephant? One fork full at a time. This is a MASSIVE
problem, with many aspects and we need to figure out how we are going
to break this down into parts each of us can manage... Further we each
bring different strengths (and weaknesses) to the table, in my own
case I dable in hardware and software, but I am less than brilliant in
both...

[Colin McGregor]

Okay, so what about packet over FRS, unlicensed and could make an
effective test bed for Vivek and other non-hams... Any issues that
anyone can think of?

[Greg Staios]

Hi guys,

Sorry for being off the radar for a bit.  Things have been pretty hectic down in my neck of the woods.  

I think the APRS idea is a good one, but we were discussing that there were some limitations with this setup as we couldn't bundle a large amount of data with this info correct.  I assume that we are planning on pairing packet for large amounts of data with aprs for geolocation?  

As for using FRS, I do know the rules state that you can't modify the radio or transmit more than 2 watts.  I haven't come across anything about digital modulation being specifically banned.  I think we need to look into it for our pilot project considering the frequencies are similar to those we plan on using.  Practically though, I hear people pumping out 50 watts and talking all over the city on these frequencies so I doubt we'd get in trouble if we put out some packet on 0.5W as a test.  The legality of this plan is another issue.  I'll try and look into it further. 

I'm currently in the process of getting a TNC (KPC-3+) and while it is an older model, we're hopeful to have a functional packet station up and running in the near future.  This will allow us to actually pilot some of the traffic once we have something together.  While I agree that this may be prohibitively expensive for widespread deployment, I do believe that a dedicated TNC will need to be placed at the basecamp to manage all the packet traffic going in and out to the internet.  As for the end user in the field, I like the ideas you guys have been throwing around.  Also, could we not just use the soundcard that is built into the computer to take care of that.  It might be slow, but it should still work.  Also, I figure that most cheap net books would be able to handle that type of work without too many problems and considering the price, size and weight of these devices, I assume that will be the most used type of computer in this instance. 

Also, we should probably get a google doc going so we can save all of our thoughts about this project so we don't need to keep going back to the emails to try and find answers.  I'm not sure whether we can do that through the group or not.  So whether we plan on going down that road or setting up a wiki, either way I'm cool.  Once it's up though, I do have a few notes that I'd like to contribute.

Hopefully I'll be able to get involved in the conversation a bit more often, but unfortunately my schedule has been ridiculous this last little while.

Thank you yet again to all of you for your hard work on this project.  It's nice to see these ideas start flying around.

Regards,
Greg

[Colin McGregor]

On Tue, Jun 14, 2011 at 9:45 AM, Greg Staios <gregs...@gmail.com> wrote:
> Hi guys,
> Sorry for being off the radar for a bit.  Things have been pretty hectic
> down in my neck of the woods.
> I think the APRS idea is a good one, but we were discussing that there were
> some limitations with this setup as we couldn't bundle a large amount of
> data with this info correct.  I assume that we are planning on pairing
> packet for large amounts of data with aprs for geolocation?

The cheap, readily available packet stuff runs at 1200 BPS. You just
can't move much data at that speed.

> As for using FRS, I do know the rules state that you can't modify the radio
> or transmit more than 2 watts.  I haven't come across anything about digital
> modulation being specifically banned.  I think we need to look into it for
> our pilot project considering the frequencies are similar to those we plan
> on using.  Practically though, I hear people pumping out 50 watts and
> talking all over the city on these frequencies so I doubt we'd get in
> trouble if we put out some packet on 0.5W as a test.  The legality of this
> plan is another issue.  I'll try and look into it further.

That would be great to know.

> I'm currently in the process of getting a TNC (KPC-3+) and while it is an
> older model, we're hopeful to have a functional packet station up and
> running in the near future.  This will allow us to actually pilot some of
> the traffic once we have something together.  While I agree that this may be
> prohibitively expensive for widespread deployment, I do believe that a
> dedicated TNC will need to be placed at the basecamp to manage all the
> packet traffic going in and out to the internet.  As for the end user in the
> field, I like the ideas you guys have been throwing around.  Also, could we
> not just use the soundcard that is built into the computer to take care of
> that.  It might be slow, but it should still work.  Also, I figure that most
> cheap net books would be able to handle that type of work without too many
> problems and considering the price, size and weight of these devices, I
> assume that will be the most used type of computer in this instance.

I have a KPC-3 (not the plus model) at home. As I previously noted, a
sound card could no doubt with some clever programming be able to
generate/decode the tones required for 1200 BPS packet, but leaves us
with the problem of manipulating the PTT (push to talk) "button". In
other words the computer has to have some way to tell the radio, it is
now time to start transmitting. With parallel ports and serial ports
finding ONE pin that could be manipulated for the PTT was fairly (or
totally) trivial, but with USB things get tougher. These days I don't
know if it is possible to find a new laptop with a parallel port or
serial port on the market. On the other hand all laptops seem to have
at least one USB port. So, we want/need inexpensive USB packet modems
(ugly, but that is the way things are...).

Some marriages I can at this point see happening are between the
following projects:

- http://www.cmlmicro.com/products/FAQs/sections/docs/614_TCM3105.pdf
- A SIMPLE packet modem (an updated version of Poor Mans Packet).
- http://www.obdev.at/products/vusb/index.html - A GPL USB 1.1 stack
for the AVR series CPU chips.
- http://arduino.cc/ - AVR based hardware that can be used for
software development (there are at least two stores in the Greater
Toronto Area that sell Arduino boards for under $30 each).

In other words, develop the software on the Arduino as the basis of a
hardware based TNC...

[Aaron Huslage]

We're basically talking about lightweight text messages here, they aren't that big. We don't need to push photos or anything.

Let's maybe start with simply getting status reports off of radios and onto Ushahidi. APRS messaging to a known gateway would probably do the trick as long as there's some standard set. Something like:

1. Controlling station is KG4FMF-9
2. All messages sent to that station will be published to http://blah
3. Please limit all messages in this vicinity to be emergency-related
4. KG4FMF-9 will gateway all direct messages to the Ushahidi instance. 
1. It could also be configured to relay position data of mobile stations that it knows about. 
2. All stations in the network could just send a simple "REGISTERME" type message to the controller which would subscribe them to the service.
3. Service could filter based on location to reduce spam or digipeater-relayed messages that we're not interested in. 
5. Controlling station could periodically send an update broadcast so new folks arriving will know what the protocol is.

We can then handle syncing over a separate frequency at a higher bitrate between stationary stations at a later time.

[Greg Staios]

Just looked into the FRS situation and looks like we're out of luck.  I've attached the RSS210 document where I obtained this from if someone wants to examine it.  We may have to look to other parts of the spectrum that don't require licensing.

A6.1.2 Emission Types and Modulation Requirements

Only emission types F3E, F1D and F2D are permitted for FRS.

Non-voice emission is permitted only for selective calling or tone-operated squelch to establish or

continue a voice communication, digital data transmission of location information or text messaging,

and is subject to the following restrictions:

(a) An FRS unit may transmit tones to make contact or to continue communications with a particular

FRS unit. If the tone is audible (greater than 300 Hz), it may be transmitted continuously no longer

than 15 seconds at a time. If the tone is inaudible (300 Hz or less), it may be transmitted

continuously only while the user is talking.

(b) The FRS unit may transmit digital data containing location information, or requesting location

information from one or more other FRS units, or containing a brief text message to another specific

FRS unit. Digital data transmissions must be initiated by a manual action or command of the user.

However, an FRS unit receiving an interrogation request may automatically respond with its

location. Digital data transmissions shall not exceed 1 second, and shall be limited to one

transmission within a 30-second period. However, an FRS unit may automatically respond to more

than one interrogation request received within a 30-second period.

[Colin McGregor]

Unfortunate, but not serious. All we REALLY care about here is a
simulated 1200 BPS data link for the likes of Vivek... for now 2 USB
to serial converters set to 1200 BPS could be made to work...

[Bernie Roche]

Dear Greg et al:

FRS is probably a waste of time for what we need, although we COULD consider its big brother, GMRS.

However, I think we need to look to a higher service...amateur radio would be one approach; another might be to operate under NGO existing licences, such as Red Cross, etc., using itinerant frequencies or those already assigned to the organization(s).

We are going to need robust systems capable of local, medium- and long- distance communications - FRS just does not suit this role.

Best Wishes,

Bernie Roche

VE3OTR

Emergency Coordinator

York Region EmComm

(416) 519-3989 res

(416) 435-0423 cell

VE3...@GMAIL.COM

 

Communicare, Resolvere, Perficere

We Communicate, We Complete, WE GET THINGS DONE

On Tue, Jun 14, 2011 at 4:10 PM, Greg Staios <gregs...@gmail.com> wrote:

[Greg Staios]

Hi Bernie,

We were mostly looking at this for a test platform so the non-ham computer guys could test some of the software. The actual system would be based on high powered amateur radios.

Greg

---

From: Bernie Roche <ve3...@gmail.com>

Sender: hamduri...@googlegroups.com

Date: Tue, 14 Jun 2011 16:34:47 -0400

To: <hamduri...@googlegroups.com>

ReplyTo: hamduri...@googlegroups.com

Subject: Re: Random thoughts...

[Bernie Roche]

Dear Greg:

I've been sick, hence the long delay in replying.

Industry Canada seems to have lightened up a bit to allow us to operate digipeaters, WinLink stations, etc., without actually being present to provide instant control.

It seems to me if Vivek (or others) want to experiment, we can help him set up a pair of low-power stations...perhaps using some older HTs, such as the Icom IC-2ATs, or the 02ATs, and used modems.

Used TNCs are readily available, and software is no problem.  And of course, experimenters can use their own laptops, or a couple of older desktops...our application doesn't require anything powerful.

At the RHoK, I took the request for used TNCs at face value, and got some, but no one in our group has said they are the ones who wanted same.  I'd like to hear who wants some, so I can recoup my costs.

Best Wishes,

Bernie

--