We ended up changing the time for the "other" Cyberguide meeting,
so I am sorry for those who showed up expecting a meeting today
at 4:30.
Some comments on Cyberguide Project Plan:
I think you are misspelling Prabhath's name.
There is a danger in the vagueness of some of the activities. Makes
it harder for the team to use this as a plan. I'll try to make some
more concrete suggestions here.
What is going to be the functionality of Cyberguide
design/implementation this quarter. Things on the list are:
indoor/outdoor positioning (automatically switchable)
2-way wireless communication using the Sharp transceivers
historical/annotation services
information browsing (with information on mobile unit or delivered on
demand from some external source)
map manipulation (zooming, path generation, scrolling)
I would expect all of these parts to be accounted for in the design
and then a clear indication which ones will be built in the new
implementation this quarter. I think one of the objectives of the
design effort should be to dictate the implementation plan for the
rest of the quarter and the Summer/Fall quarters, as well as providing
a test plan. We have had some success with our informal design
allowing us to build Cyberguide in pieces. This new design should
make it entirely possible for us to improve on that success.
I'm very worried about the communications part of the project. This
is a critical piece to making Cyberguide a worthwhile product.
Someone needs to be looking at the Sharp units and talking to Chris
Atkeson about how they are to be built.
Resources:
What is the plan for this? If someone can find the best price for a 17-20
inch monitor for Santana, then I will authorize a purchase. I have the
name of a reseller in Atlanta with which I have a $300 credit and I would
like someone to come get the information from me to call them. Do we
need extra copies of the Newton books? There were multiple copies
already around for Cyberguide. Do we know where they are now? Also, Sue
put together a Newton tutorial that should be reconsulted for training
purposes. We also have copies of the Newton references. Rob Kooper got
the 1.6 version of NTK and that should have been installed on
Santana. Check with Sue about on-line Newton reference material. If
there is a Delphi book in the campus bookstore, it is a simple matter
to get a purchase order and go and pick it up. Someone on the Delphi
team should contact me about that.
Schedule:
Can you put this in a tabular format to make it a little easier to
read?
Plan on having the midterm presentation on 4/24. You should check
with Spencer about scheduling the classroom (102) and making sure the
rest of the RWL class is going to be there. I'm going to be out of
town on 4/25-26.
Find out the date of the May GVU Demo Day and make that explicit in
the schedule because that will be a critical demonstration date for
the RWL this quarter.
In a recent message you wrote:
> Basic IR and Communications Information
> (Summary of discussion w/ Sue Long)
>
> There have been lots of questions lately on Communications and Positioning,
> what's going on, and who has to do what with what. Here are some salient
> points that will undoubtedly prove helpful, that Sue talked a little about
> this afternoon. If you have any questions, feel free to email me back
> (or find Sue. She's *really* good at this stuff). Thanks.
>
>
> Lesson 1: To communicate, both devices must speak the same language.
>
> Sue's first point was that, to transmit any information, the device
> sending the info and the device receiving the info must both be using
> the same frequency.
>
> Remotes: Transmit Only. 15 Hz*.
> Sharp Tranceivers: Receive or Transmit. 500 Hz.
> Newtons: (have sharp tranceivers inside of them.) Receive/Transmit @ 500 Hz.
>
> The above are non-configurable. They cannot be changed.
>
> The Motorola hardware device that currently sits atop the Newton to
> give it positioning info, however, is (according to Chris Atkenson)
> configurable. The code should be modifiable, so that someone can tell
> it what frequency to expect when it is receiving data.
> Currently it receives 15 Hz, the same as the remotes. This was originally
> built to get around the fact that the Newtons can't receive the remote
> control signals, due to the speed differences.
>
>
> Sue had some suggestions for both teams.
>
> Newton:
>
> Idea #1:
> You have a choice. You can do positioning the way it is currently
> implemented (that is, keep the Motorola hardware with the Newton
> to read the remote control positioning signals). Then, you could use
> sharp tranceivers to send communications data at 500 Hz, which the
> Newton could use its internal sharp tranceiver to receive.
>
> <OR>
>
> Idea #2:
> Or you could scrap the Motorola and the remotes and do everything with
> the transceivers. (See below for more info on how **)
>
>
> PC:
>
> Idea #1:
> To deal with positioning, Sues first suggestion was that you look at the
> positioning code built in Visual Basic, and just port it into Delphi.
> Then, use the Sharp tranceivers (one for sending, another attached to
> the pc for receiving) for communications.
>
> <OR>
>
> Idea #2:
> Just like the newton team, you could use the tranceivers to send both
> positioning and communications info. (Again, see below **)
>
>
> ADVANTAGES: of using the tranceivers
>
> 1) If both systems were using the tranceivers for positioning and communicati
>ons,
> then both could use the same sending system (how's that for platform
> independance). Ie, we have one system of transceivers that broadcasts
> positioning/communications, and all of the Cyberguides, regardless of
> platform, pick up the same signals, then do with them as they will.
> Cool, huh! Of course, this assumes that both groups agree with what the
> tranceivers are sending (ie one group doesn't want just positioning info,
> and one group just communications)...
>
> 2) This also means that the Newtons and PCs could talk to each other, as
> well as get signals from the broadcasting system. (Again, a plus for
> platform independance).
>
>
> ... just some ideas!
>
> (BELOW)
>
> * Hz -- Sue wasn't exactly sure on this. Hz, MHz, whatever ... that's
> not the important part. The speeds are different (the important part)!
>
> ** On mixing Positioning/Communicatins --
> Sues two suggestions on this idea, was that it may be possible to either
> 1) Have a prefix bit that indicates what the rest of the message is
> 2) Always include positioning info, even in comm. messages.
>
>
> Thanks.
> Nancy
>