Dan, Steve,

S. Sampson wrote:
If you don't use a specified code, you must identify using a specified code.
For example, if you design your own protocol (unspecified code), then you
should design the system to ID every 10 minutes, or every transmission.

That should not be a problem. I envisage we would use an unspecified
code for our data transmissions, but we could self-identify with an RTTY
broadcast every 10 min. This will all be computer-controlled so that
should be easy.

Yes. Phil Karn proposed a DES authentication many years ago, however, I
don't see why just a plain old MD5 checksum of the data and the time-stamp
wouldn't fit most requirements.

Our motivation for authentication is that we are concerned with
controlling access to the sensor network; for instance, we want to be
the only ones who can give commands to the sensor nodes, like "turn off."

I don't see a problem in what you are proposing, and I think you could enlist
several amateurs who wanted to help. It goes without saying, that you would
need a ham license yourself, but that is pretty simple these days on a no-code
ticket.

I should have mentioned, I have a NCT license: KD5SZT. Issued last
summer. That's a great idea, getting hams involved. I think it would be
a fun project.

Even if the money you use to buy the equipment, and power the equipment,
is grant money, it would be legal. Where you would begin to have problems,
is if you made the data proprietary, or sold subscriptions/membership/access
to say web sites where the data is stored. You could maintain a compilation
type copyright, and restrict access to the raw data and software, if you provided
say access to the processed data. I'm being vague, but the gist of it, is that you
can't make money, and I never heard of a research program that did.

Our goal is to provide a "service" to researchers; no compensation would
ever be accepted and the network is only for use in relaying sensor data
and sending commands to said sensors. Data produced would be freely
available. Sounds like our application is OK with the use policies.

Steve, thanks for your input!

Dan/W4NTI wrote:
Do you have, or are you going to have, a ham license? Will all the
stations involved have a ham licensee on hand? If not you will run
into difficulties with the third party rules.

I do have a NCT license. I can imagine getting my advisor to get a
license, but I'm interesting in seeing if I can get around that. As I
see it, there would be several autonomous transmitters (relay devices)
and one control station, all of which would be under my control. As I do
sleep some of the time, is that a problem?

What you describe may fall under 'experimental'. But I would check
with the
FCC.

We want to design our system so that any manner of communication means
could be used to ferry the sensor data (internet, etc). But for our
initial experimentation, I think ham radio would be (a) very appropriate
and affordable and (b) fun. We will probably use ISM for short-range
communications and only rely on ham for longer range xmits.

You may want to try Mr. Hollingsworth at FCC and see what he says. He is
chief of enforcement, FCC. Or maybe he can direct you to the proper
desk.

Great, thanks for the reference. I will contact him.

Regards,

--
Leo Szumel | ECE Graduate Student, UC Davis | KD5SZT
Email:

Note: The following is just my interpretation of the rules.

In article , Leo Szumel
writes:

If you don't use a specified code, you must identify using a specified
code.
For example, if you design your own protocol (unspecified code), then you
should design the system to ID every 10 minutes, or every transmission.

That should not be a problem. I envisage we would use an unspecified
code for our data transmissions, but we could self-identify with an RTTY
broadcast every 10 min. This will all be computer-controlled so that
should be easy.

I think there's a problem with using a code that is not publicly available. ID
is not enough; if the message cannot be read by a suitably-equipped monitoring
station (read: FCC) what you have is a form of encryption.

Amateurs are not allowed to intentionally encrypt or otherwise conceal
transmission meaning or content, with one exception: remote control commands.
So the "turn off" command would be OK to encrypt, but not the data coming from
the remote sensors.

73 es GL de Jim, N2EY

Hi Jim,

N2EY wrote:
I think there's a problem with using a code that is not publicly available. ID
is not enough; if the message cannot be read by a suitably-equipped monitoring
station (read: FCC) what you have is a form of encryption.

Amateurs are not allowed to intentionally encrypt or otherwise conceal
transmission meaning or content, with one exception: remote control commands.
So the "turn off" command would be OK to encrypt, but not the data coming from
the remote sensors.

I see your point. How about this, though:

97.217:

"Telemetry transmitted by an amateur station on or within 50 km of the
Earth's surface is not considered to be codes or ciphers intended to
obscure the meaning of communications."

97.3(45):
"Telemetry. A one-way transmission of measurements at a distance from
the measuring instrument."

Also, 97.309(b) indicates that unspecified codes can be used so long as
the purpose is not to obscure the meaning of a communication.

Thanks for your input,

-Leo

--
Leo Szumel | ECE Graduate Student, UC Davis | KD5SZT
Email:

In article , Leo Szumel
writes:

Hi Jim,

Hello Leo

N2EY wrote:
I think there's a problem with using a code that is not publicly available.
ID
is not enough; if the message cannot be read by a suitably-equipped
monitoring
station (read: FCC) what you have is a form of encryption.

Amateurs are not allowed to intentionally encrypt or otherwise conceal
transmission meaning or content, with one exception: remote control
commands.
So the "turn off" command would be OK to encrypt, but not the data coming
from
the remote sensors.

I see your point. How about this, though:

97.217:

"Telemetry transmitted by an amateur station on or within 50 km of the
Earth's surface is not considered to be codes or ciphers intended to
obscure the meaning of communications."

97.3(45):
"Telemetry. A one-way transmission of measurements at a distance from
the measuring instrument."

Also, 97.309(b) indicates that unspecified codes can be used so long as
the purpose is not to obscure the meaning of a communication.

Good point!

As I interpret it, what this means is that the telemetry message doesn;t have
to be self-explanatory. For example, a remote sensor might report "534A0" as a
telemetry message in, say, ASCII, which is a "specified code", but there's no
need to have the remote sensor indicate what the symbols mean.

Thanks for your input,

You're welcome!

73 de Jim, N2EY