rcpilot-devs — R/C Pilot Developers

Re: [rcpilot-devs] Preferences/Options Dialog

[Ian D. <occ...@ia...>]

Michael J. Pawlowsky wrote:
> So this is the info we need to store that I can think of so far.
> Ian do you want to start off with this? Or is there something else that interests you more.

Sure, I'll take a stab at it. I'll have the first version ready by 
Thursday evening.

--ian

[rcpilot-devs] Preferences/Options Dialog

[Michael J. P. <mi...@vi...>]

So this is the info we need to store that I can think of so far.
Ian do you want to start off with this? Or is there something else that interests you more.


Preferences Dialog

Data

(radio button)
 -AGWPE  - IP
         - Port

(radio button)
 -Serial - Comm Port


Colors
- Background
- Foreground
- Warnings


Alarms
checkbox   - value (should show unit prefs)
 - Distance (on/off) - How far


Units
(radio buttons)
 - Metric
 - Nautical
 - Imperial


Identifictaion
- Remote Vehicle Call Sign  (6 alphanumeric + 1 numeric)
- Ground Station Call Sign   (6 alphanumeric + 1 numeric)

GPS
 - Set Home Lat/Lon in [deg min.xxx] (button aquire from GPS)

[rcpilot-devs] Prefs

[Michael J. P. <mi...@vi...>]

I had changed Prefs to be create an object, but after reading about the API again I put it back to being static.
The way I see it, that's really the way it was intended to be used.

Preferences itself is an abstract class.

Also there never will be, or should be more than one instance of the user preferences.


Mike

RE: [rcpilot-devs] Initial comments on RCGS codebase

[Michael J. P. <mi...@vi...>]

Feel free to create it's own package if you think that's best.
I have no real preference either way.

As for removing the static variables and methods, also not a problem.
I starting doing that with the TelemetryData.
I was not planning on it for the Prefs since there will never be more than one instance of it,
but It's not a problem to do so. I think that would be the only stuff that you will need access to.
But if there are others let me know.

Mike


*********** REPLY SEPARATOR  ***********
>network events onto the event dispatch queue.  I agree that the AGW classes
>should be in a separate package. I put the AGW on as a prefix because that
>structure didn't exist.
>
>Other things:
>
>I'd get rid of most the static methods and variables, I keep running afoul
>of those.  The network code requires real objects.  If the system requires
>restricting this stuff to a single instance, we could use the Singleton
>pattern, but please use synchronized, double checked locking doesn't work.
>/peter

[rcpilot-devs] Java Style Guide

[Michael J. P. <mi...@vi...>]

I put up a style guide at:

http://rcpilot.sourceforge.net/docs/javastyle.html

**** Let me know what you think ****

As mentioned earlier, I'm not anal about these things at all. In fact the exact opposite.
But we, especially me, should start to have some conformity in the code to make it easier for others that will contribute.

Mike

Re: [rcpilot-devs] Initial comments on RCGS codebase

[Michael J. P. <mi...@vi...>]

>My biggest general suggestion is that we refactor classes to make them
>more focused on doing a particular job, which will make it easier for us
>to extend and debug them later on. Adding some sub-packages to rcgs
>would help too.

I find them all pretty focused already. What do you think Peter?

>---------------------------
>AGW classes
>---------------------------

Perhaps the name is less meaningful to you because you are not actively flying yet, or involved with packet radio, APRS etc.
What it actually is, is part of the authors call sign. In amateur radio when people put out products, they usually do so under the name of their call sign.
Perhaps it's a little vain, but it's a tradition. AGWPE is the AGW packet engine. It is a very recognized name amongst people that are involved in amateur radio.
To use the power most of us use in our transmitter on the plane, in most countries you need to be an licensed amateur radio operator.

>---------------------------
>Altimeter, Attitude, Compass, IAS, Tachometer, Variometer
>---------------------------

I don't see this project big enouh personally to have many packages. We have almost all the classes we will be using for version 1 at least.
If it really grows later on perhaps.
As for knowing their positions, yes they need to know it because they are absolute position in relation to the panel image.
Not everyone will want the same instruments. So you can create your own panel, place the instruments on it and you now have a custom instruments panel.
It knows what instruments to use by reading the properties file. Not the best place to keep that info, but seem like the best place for now.
Basically it woul be the equivalent of a rcgs.ini file on win. or an xml prefs file on *nix.
At one point I will probably simply move it out of rcgs.properties into something like instrument.properties and not localize the request.


>---------------------------
>Global.java
>---------------------------

Absolutely nothing. Well holds two variables for now until I figure out where I want them.
It use to be the TelemetryData.

>---------------------------
>InstrumentLayout
>---------------------------

Beacuse none were specific enough for laying out the instruments.
Trust me I wouldn't have written one otherwise. Basically you can resize the panel and everything will stay aligned and centered on it.
The type 99 stuff is temporary for now to have the JTextField for debugging.

>---------------------------
>ImagePanel
>---------------------------

ImagePanel creates an JPanel using an image as a background instead of a color. In our case it paints the vackground of the instrument panel on the JPanel.

>---------------------------
>JMenuBar
>---------------------------

Really does not make a difference to me. If you want to move it to it's own class, go ahead.


>---------------------------
>Monitor
>---------------------------
>
>What does the Monitor class do? I'm unclear about "show incoming packets
>from AGWPE". Is there a more descriptive name we could give this class?


It's basically a debugging tool. It allows you to view the incoming frames.
It seems evident to me, but that's probably because I have a monitor in many other apps that I use in packet radio etc.
Kind of like the AGWPE thing, if you were a HAM and used packet radio stuff, it would be more eveident I believe.


>---------------------------
>Prefs
>---------------------------

>I think we should consider abstracting the properties file into
>its own Java class, so only one class has to actually call
>properties.getProperty().

As an abstract class I can see that. But creating an instance of it I don't see why.
In the near future it will be called a lot for internationalization. I will put out a french version once v1.0 (aka FirstFlight) is complete.
But I don't really mind either way. Feel free to break it out if you like.

>I'm not clear about the function of the Prefs class... is this the
>preferences dialog box? Or does it store data?

It does both.....
If you want to split that up no problem there.

I'm still playng with the storing of values quite a bit.
So don't get too attached to it right away. Or if you want to start with the preferecnes dialog feel free to redo it.

I use to create an instance of Preferences for each sub-group of Prefs (rcgs/tracker, rcgs/map etc.). I liked that and it worked well.
But know I'm trying to only have one instance of Preferences and from what I read it should be able to create
sub-groups from there, but I don't have that working yet.


>---------------------------
>Rcgs.java
>---------------------------
>
>This is just personally preference, but I think it would make sense for
>the Rcgs class to be renamed GroundStationDriver.java, or RcgsDriver, so
>it's clearer that that's the main method for the application.

I want to brand RCGS as the name.
You will end up seeing it on the website, opening screen etc.


>---------------------------
>TelemetryData
>---------------------------
>Is there any reason that instance variables in TelemetryData are
>public? (instead of private)

No reason anymore. It was all static earlier, and I was accessing them from all over the place.
That changed yesterday. So yes they can become private.


>---------------------------
>Tracker
>---------------------------
>
>Tracker class probably shouldn't know anything about the GPS class.  The
>guts of getBearing() and getDistance() feel like something we should
>refactor into a model class (is that what the comment "DISTANCE AND
>BEARING WILL BE IN TelemetryData" means?).

Basically that's what it means.
The calculation of distance and bearing will be done at the same time all the data is parsed from incoming frames.
So it will end up in Agwpe.java Or probably create a new class of all the telemetry calculations, or move it to TelemetryData.
Haven't figured all that part out yet. But what needs to be kept in mind is that AGWPE is one transport method.
There will also be a second one that will be serial communication.

The values are stored in TelemetryData now.

Let me know what you will work on, and try to focus on one task at a time.
I have been loosely using the task manager on SourceForge, but I will start using it more.
Which goes the same for all you ideas. Not to forget them we should put them in the feature request
stuff and move them to tasks when we decide to implement them.

Also I need to start a quick style guide somewhere. I have not been very good about style for this project.
But here are the basics that if you can follow would be great.
I also need to desperately conform to this since I usually just code and worry about cleaning up later.
I'm not anal about this at all, but if you can try to follow it, as I will try to do, that would be great.


All major sections (methods etc.) should start with a comment in the form of:

/*
*
*
*
*/

All comments inside of a major section should only use // style comments.

4 spaces are used for indentation. No tabs should be used, only spaces.
I also constantly forget to do his, but most IDEs have a convert tabs to spaces fuction.
Perhaps at one point I will create a script to include in cvs to do this automatically.
The reason behind this is that cvs does see spacing in a diff. And if tab repaces 4 spaces etc, it will show it as a version diff.
Since I'm constantly lookign at the diffs to make sure no one has commited something I'm working on I appreciate it not showng diffs for spaces.


This one I need to go through everything and change for my stuff.

All vars should be lower case and names should use _ to seperate words.  so...  gps_altitude gps_sog etc.
Methods should use upper and lower case like starting with a lower case. getAltitude(), setAltitude.
Classes should start with an upper case TelemetryData, or all upper case is acceptable as well like CRC.



Mike

Re: [rcpilot-devs] CVS package structure

[Michael J. P. <mi...@vi...>]

I keep 2 CVS servers, one at home and one at the office that I could not live without them.
I am far from a CVS poweruser, but I must say I love CVS. ;-)

I also installed Eclipse last week, but got a little frustrated by it's CVS interface.
So I dropped it for now, but I will probably go back to it because my demo is about to run out on the IDE that I'm using.

Personally I keep the command line stuff for CVS on my Win and Linux boxes.
I use a combination of WinCVS and the command line.

>BTW, I gave up on winCVS and am using Eclipse for CVS now, which seems
>to be working a lot better.

RE: [rcpilot-devs] Initial comments on RCGS codebase

[PK W. <pe...@wo...>]

Ian,

AGW:

I can't remember what it stands for, but the AGW classes are all NIO
networking classes. Agwpe is the only class in that group that needs to know
anything about swing or that needs to be public if it were in its own
package.  It connects to the network classes and uses invokeLater to put the
network events onto the event dispatch queue.  I agree that the AGW classes
should be in a separate package. I put the AGW on as a prefix because that
structure didn't exist.

Other things:

I'd get rid of most the static methods and variables, I keep running afoul
of those.  The network code requires real objects.  If the system requires
restricting this stuff to a single instance, we could use the Singleton
pattern, but please use synchronized, double checked locking doesn't work.
/peter


-----Original Message-----
From: rcp...@li...
[mailto:rcp...@li...] On Behalf Of Ian Dallas
Sent: Wednesday, March 03, 2004 5:14 AM
To: R/C Pilot Developers List
Subject: [rcpilot-devs] Initial comments on RCGS codebase

Just a note up front... I went through the codebase pretty quickly, so feel
free to disregard any of this. They're just some ideas to get the ball
rolling.

My biggest general suggestion is that we refactor classes to make them more
focused on doing a particular job, which will make it easier for us to
extend and debug them later on. Adding some sub-packages to rcgs would help
too.

---------------------------
AGW classes
---------------------------

Could you explain how the AGW classes work together, and how the GUI works
with them? My sense is that they might belong in their own package. They
seem to have a lot of relationship to each other, and not so much of a
relationship to the rest of the GUI. If possible, we might want to make
Agwpe the only public class in the package, and have all the other AGW
classes package-private.

Agwpe could probably also use a more descriptive name.

---------------------------
Altimeter, Attitude, Compass, IAS, Tachometer, Variometer
---------------------------

Could we move instruments to a new package, like rcpilot.rcgs.instruments?

Is there a reason that the individual instruments need to know their xy
coordinates on initialization? It seems like that should be handled by the
class that's creating the instrument panel.

---------------------------
Global.java
---------------------------

Why is there a Global class? What does it do?

---------------------------
InstrumentLayout
---------------------------

Why do we need to create our own subclass of LayoutManager? Were none of the
available LayoutManagers flexible enough for our needs?

---------------------------
ImagePanel
---------------------------

What does the ImagePanel class do?

---------------------------
JMenuBar
---------------------------

I think all the JMenuBar stuff in Rcgs.java should be moved into a separate
class that subclasses JMenuBar. Creating menubars gets messy, and there's no
reason any other class needs to be bothered with it.

---------------------------
Monitor
---------------------------

What does the Monitor class do? I'm unclear about "show incoming packets
from AGWPE". Is there a more descriptive name we could give this class?

---------------------------
Prefs
---------------------------

I think we should consider abstracting the properties file into its own Java
class, so only one class has to actually call properties.getProperty().

That'll save us the trouble of having code asking for property names, and of
having to parse Strings into int's everywhere, and give us compile-time
checking.

I'm not clear about the function of the Prefs class... is this the
preferences dialog box? Or does it store data?

---------------------------
Rcgs.java
---------------------------

This is just personally preference, but I think it would make sense for the
Rcgs class to be renamed GroundStationDriver.java, or RcgsDriver, so it's
clearer that that's the main method for the application.

---------------------------
TelemetryData
---------------------------
Is there any reason that instance variables in TelemetryData are public?
(instead of private)

---------------------------
Tracker
---------------------------

Tracker class probably shouldn't know anything about the GPS class.  The
guts of getBearing() and getDistance() feel like something we should
refactor into a model class (is that what the comment "DISTANCE AND BEARING
WILL BE IN TelemetryData" means?).

--ian


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with a free DVD software kit
from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
rcpilot-devs mailing list
rcp...@li...
https://lists.sourceforge.net/lists/listinfo/rcpilot-devs

[rcpilot-devs] Initial comments on RCGS codebase

[Ian D. <occ...@ia...>]

Just a note up front... I went through the codebase pretty quickly, so 
feel free to disregard any of this. They're just some ideas to get the 
ball rolling.

My biggest general suggestion is that we refactor classes to make them 
more focused on doing a particular job, which will make it easier for us 
to extend and debug them later on. Adding some sub-packages to rcgs 
would help too.

---------------------------
AGW classes
---------------------------

Could you explain how the AGW classes work together, and how the GUI 
works with them? My sense is that they might belong in their own 
package. They seem to have a lot of relationship to each other, and not 
so much of a relationship to the rest of the GUI. If possible, we might 
want to make Agwpe the only public class in the package, and have all 
the other AGW classes package-private.

Agwpe could probably also use a more descriptive name.

---------------------------
Altimeter, Attitude, Compass, IAS, Tachometer, Variometer
---------------------------

Could we move instruments to a new package, like rcpilot.rcgs.instruments?

Is there a reason that the individual instruments need to know their xy
coordinates on initialization? It seems like that should be handled by
the class that's creating the instrument panel.

---------------------------
Global.java
---------------------------

Why is there a Global class? What does it do?

---------------------------
InstrumentLayout
---------------------------

Why do we need to create our own subclass of LayoutManager? Were none of 
the available LayoutManagers flexible enough for our needs?

---------------------------
ImagePanel
---------------------------

What does the ImagePanel class do?

---------------------------
JMenuBar
---------------------------

I think all the JMenuBar stuff in Rcgs.java should be moved into a
separate class that subclasses JMenuBar. Creating menubars gets messy, 
and there's no reason any other class needs to be bothered with it.

---------------------------
Monitor
---------------------------

What does the Monitor class do? I'm unclear about "show incoming packets 
from AGWPE". Is there a more descriptive name we could give this class?

---------------------------
Prefs
---------------------------

I think we should consider abstracting the properties file into
its own Java class, so only one class has to actually call 
properties.getProperty().

That'll save us the trouble of having code asking
for property names, and of having to parse Strings into int's
everywhere, and give us compile-time checking.

I'm not clear about the function of the Prefs class... is this the 
preferences dialog box? Or does it store data?

---------------------------
Rcgs.java
---------------------------

This is just personally preference, but I think it would make sense for
the Rcgs class to be renamed GroundStationDriver.java, or RcgsDriver, so
it's clearer that that's the main method for the application.

---------------------------
TelemetryData
---------------------------
Is there any reason that instance variables in TelemetryData are
public? (instead of private)

---------------------------
Tracker
---------------------------

Tracker class probably shouldn't know anything about the GPS class.  The 
guts of getBearing() and getDistance() feel like something we should 
refactor into a model class (is that what the comment "DISTANCE AND 
BEARING WILL BE IN TelemetryData" means?).

--ian

[rcpilot-devs] CVS package structure

[Ian D. <occ...@ia...>]

Peter Wooster wrote:
>   We should sort out the package structure in the CVS before the group of
> developers gets any bigger.  Its making builds very difficult for those that
> use the standard Sun tools.  

I agree with Peter.

I'd also like to say right now how much I *hate* cvs and winCVS. It took 
me 4 hours to get everything working... madness.

BTW, I gave up on winCVS and am using Eclipse for CVS now, which seems 
to be working a lot better.

--ian

RE: [rcpilot-devs] TelemetryData

[Michael J. P. <mi...@vi...>]

OK you should now checkout "src" and you will have that directory structure.
The only downside to this for me is that all the class files end up in the same forlder as the source files.

Basically what I had was another rcpilot/rcgs folder structure in my rgcs CVS  folder that contained all the classes etc.
But not a big deal. I'll have to fix up my build scripts also. I have a nice little batch files that created the jars zipped everything up, sftp'd it to the server and then cleaned everything. It made adding a version on the site a one command task.


Mike




>.src
>   .art
>   .res
>   .rcpilot
>      .rcgs
>      .common
>      .testserver

[rcpilot-devs] Changed the test server

[Michael J. P. <mi...@vi...>]

Peter....

The test server should now be sending out AGWPE packets.
Also feel free to wipe out getAGWPEVersion in Agwpe.java.

[rcpilot-devs] TestServer

[Michael J. P. <mi...@vi...>]

OK I was putting out AX.25 Frames... Sorry about that.
I will change it to match AGWPE Frames.


*********** REPLY SEPARATOR  ***********

>I tried connecting to the TestServer, it appears to not be putting the 36
>byte header on the packets. Is it supposed to, or am I missing something?

RE: [rcpilot-devs] TelemetryData

[Michael J. P. <mi...@vi...>]

I don't mind changing the structure at all.
I can re-create the project in the IDE rather quickly.

So.. O.K. DO you want to commit everything you have right now.
And I will checkout a fresh copy.

I will then change the directory structure and add everything and send out a mail when it is done.


Mike





>use the standard Sun tools.  I don't know if your IDE makes that flat
>structure work but I would prefer if the package structure was available
>under src. Eg:
>
>.src
>   .art
>   .res
>   .rcpilot
>      .rcgs
>      .common
>      .testserver
>
>This way I could simply checkout from .scr and compile and run in the
>resulting directory.  As it is I'm constantly copying between the cvs
>"working copy" and a set of directories that follow the package structure.
>Is there some way to map this stuff?  I'm using WinCVS and the
>documentation
>is pitiful.
>/peter

RE: [rcpilot-devs] TelemetryData

[Peter W. <pe...@wo...>]

There is a JColorChooser that lets you pick colours,  the usual way to store
the resulting colours is as integers encoding the three RGB values together
as returned by Color.getRGB(). 

I tried connecting to the TestServer, it appears to not be putting the 36
byte header on the packets. Is it supposed to, or am I missing something? 

As to where the packet parser should go, the Agwpe.Txin method will be
called for every incoming packet, the argument is an AGWPacket which has
methods that return individual header fields and the data and header as
ByteBuffers.

  We should sort out the package structure in the CVS before the group of
developers gets any bigger.  Its making builds very difficult for those that
use the standard Sun tools.  I don't know if your IDE makes that flat
structure work but I would prefer if the package structure was available
under src. Eg:

.src
   .art
   .res
   .rcpilot
      .rcgs
      .common
      .testserver

This way I could simply checkout from .scr and compile and run in the
resulting directory.  As it is I'm constantly copying between the cvs
"working copy" and a set of directories that follow the package structure.
Is there some way to map this stuff?  I'm using WinCVS and the documentation
is pitiful.
/peter   

-----Original Message-----
From: rcp...@li...
[mailto:rcp...@li...] On Behalf Of Michael J.
Pawlowsky
Sent: Tuesday, March 02, 2004 7:41 PM
To: R/C Pilot Developers List
Subject: RE: [rcpilot-devs] TelemetryData


OK cool....

I'm working on prefs right now, I'm not sure about what the best way to
store a Color would be.

I tried using Color.toString and then setting the color.getColor(String) but
that doesn't seem to be working for me.

For some reason I can't get to java.sun.com right now to look it up.
I was just wondering if you knew of what the ideal method would be.
I could use rgb values and either set one Pref for each, or in a String and
parse the string, but I'm thinking there's a better method.
I can save Prefs as Strings, floats, long, ints....

By the way I made changes in many files today so you might want to update.

Cheers,
Mike





*********** REPLY SEPARATOR  ***********

On 02/03/2004 at 7:19 PM PK Wooster wrote:

>Mike,
>I'm going to see if I can get Rcgs talking to my echo server.  Once 
>that works I'll install methods that will deal with the incoming packets.
>/peter





-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with a free DVD software kit
from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
rcpilot-devs mailing list
rcp...@li...
https://lists.sourceforge.net/lists/listinfo/rcpilot-devs

RE: [rcpilot-devs] TelemetryData

[Michael J. P. <mi...@vi...>]

OK cool....

I'm working on prefs right now, I'm not sure about what the best way to store a Color would be.

I tried using Color.toString and then setting the color.getColor(String) but that doesn't seem to be working for me.

For some reason I can't get to java.sun.com right now to look it up.
I was just wondering if you knew of what the ideal method would be.
I could use rgb values and either set one Pref for each, or in a String and parse the string, but I'm thinking there's a better method.
I can save Prefs as Strings, floats, long, ints....

By the way I made changes in many files today so you might want to update.

Cheers,
Mike





*********** REPLY SEPARATOR  ***********

On 02/03/2004 at 7:19 PM PK Wooster wrote:

>Mike,
>I'm going to see if I can get Rcgs talking to my echo server.  Once that
>works I'll install methods that will deal with the incoming packets.
>/peter

RE: [rcpilot-devs] TelemetryData

[PK W. <pe...@wo...>]

Mike,
I'm going to see if I can get Rcgs talking to my echo server.  Once that
works I'll install methods that will deal with the incoming packets.  
/peter 

-----Original Message-----
From: rcp...@li...
[mailto:rcp...@li...] On Behalf Of Michael J.
Pawlowsky
Sent: Tuesday, March 02, 2004 10:34 AM
To: R/C Pilot Developers List
Subject: [rcpilot-devs] TelemetryData


TelemetryData now holds all the data that we will get from the remote
vehicle.
An instance of it is created in Rcgs called tdata.

You should use get and set to retrieve and set the data values.
ie. tdata.getAltitute();
    tdata.setAltitude(1000);

It seemed like a bit too much work to have every piece of data have a change
event.
So basically I'm thinking a glodal data changes event will be fired by
whatever will parse the data and set it.

The JPanel will listen for the events to know when it needs to update
itself.
This means that some items will be updated for no reason (when we are not
using that data type), but it just doesn't seem necessary to have every data
<displayer>  listening for change events.

I'll spend the next little while cleaning up things and moving what I've
done so far to this model.

Peter: when you get a chance, can you create a method somewhere to parse the
data.
I can do the actual parsing code, CRC checking, setting of the data etc. if
you want, but just place it somewhere and let me know where.
It should get the data from testServer.

If Ian gets on board next week, I will back off a bit from rcgs to work on
some other stuff.
Other things I would like to work on in the next couple of weeks:

	Finish the RFC for the new AX.25 Frame type and submit it to the
APRS SIG.
	Make a proto board for the 1200 baud modem (although not optimal for
refresh rates at least it will give us something to work with)
	Work on the altitude instrument (finish schematic and breadboard
with new design to improve resolution)

Cheers,
Mike





-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with a free DVD software kit
from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
rcpilot-devs mailing list
rcp...@li...
https://lists.sourceforge.net/lists/listinfo/rcpilot-devs

[rcpilot-devs] How many lines....

[Michael J. P. <mi...@vi...>]

In case anyone is curious, we are up to 5429 lines of code in rcgs.
Still a relatively small app.

I did a line count simply because adding in all the datatypes to TelemetryData seemed like a lot of lines!


:-)

[rcpilot-devs] TelemetryDataChanged Events

[Michael J. P. <mi...@vi...>]

OK well it works...  Yeah!

I only have it going for altitude but we now get the value changing in all 3 views that have the TelemetryTable.

Basically once you enter the data in the JTextField on the instruments page (this is what the data parsing stuff needs to replace) you call
tdata.fireTelemetryDataChanged();

Each instance of the TelemetryTable adds a listener to the DataChange events.
So when the event gets fired each instance of the TelemetryTable updates its own values.

As I said before, I almost hate to admit this, but I'm only in week 3 or so of my Java training.
This totally seems like the way to do this to me, but any comments are welcomed.

The question I have now is should I have each instrument also register to receive these events.
Right now it relies on repaint being called. Which is ok since we only need them to update values if they are seen.
But perhaps to stay a little more homogenous we should also have instruments handle dataChange events.
We could also do something as simple as checking to see if it's visible or not to decide on wether to update the instrument.

Cheers,
Mike

Re: [rcpilot-devs] 9600 bds FSK modem.

[Michael J. P. <mi...@vi...>]

Even though I read it last week, I don't even remember why they use scrambling anymore.
Was it not to have a sequence of many 0's and 1's in a row or something?

My head decided not to retain it. I keep feeling like I've reached my limit of information and whenever I remember something I need to toss something else out!  ;-)

Hope someone else will be more help. I still haven't heard form John on the AmSat site.
I'll give him a few more days a then repost my mail to him.

Mike



*********** REPLY SEPARATOR  ***********
>Has anybody looked at the data scrambling algorithms
>before?
>

[rcpilot-devs] 9600 bds FSK modem.

[Val P. <val...@ya...>]

I need help figuring out how data are scrambled in 9600 bd FSK
modems.
The link that Mike posted recently:
http://www.amsat.org/amsat/articles/kd2bd/...m/9k6modem.html
suggests one scrambling method.
Source code for FlexNet FSK modem (attached) has the following
scrambling procedure:

***
#define DESCRAM17_TAPSH1  0
#define DESCRAM17_TAPSH2  5
#define DESCRAM17_TAPSH3  17

#define SCRAM17_TAP1  (1<<DESCRAM17_TAPSH3)
#define SCRAM17_TAPN  ((1<<DESCRAM17_TAPSH1)|(1<<DESCRAM17_TAPSH2))

***
s->scram = (s->scram << 1) | ((s->scram ^ bits ^ 1) & 1);
bits >>= 1;
if (s->scram & (SCRAM17_TAP1 << 1))
s->scram ^= SCRAM17_TAPN << 1;
s->txbits = (s->txbits << 1) | ((s->scram >> DESCRAM17_TAPSH3) & 1);
***


I don't think they are the same. I've tried both with my modem setup
and none worked. Has anybody looked at the data scrambling algorithms
before?
Regards,
Val. 


=====


__________________________________
Do you Yahoo!?
Yahoo! Search - Find what you’re looking for faster
http://search.yahoo.com

[rcpilot-devs] TelemetryData

[Michael J. P. <mi...@vi...>]

TelemetryData now holds all the data that we will get from the remote vehicle.
An instance of it is created in Rcgs called tdata.

You should use get and set to retrieve and set the data values.
ie. tdata.getAltitute();
    tdata.setAltitude(1000);

It seemed like a bit too much work to have every piece of data have a change event.
So basically I'm thinking a glodal data changes event will be fired by whatever will parse the data and set it.

The JPanel will listen for the events to know when it needs to update itself.
This means that some items will be updated for no reason (when we are not using that data type),
but it just doesn't seem necessary to have every data <displayer>  listening for change events.

I'll spend the next little while cleaning up things and moving what I've done so far to this model.

Peter: when you get a chance, can you create a method somewhere to parse the data.
I can do the actual parsing code, CRC checking, setting of the data etc. if you want, but just place it somewhere and let me know where.
It should get the data from testServer.

If Ian gets on board next week, I will back off a bit from rcgs to work on some other stuff.
Other things I would like to work on in the next couple of weeks:

	Finish the RFC for the new AX.25 Frame type and submit it to the APRS SIG.
	Make a proto board for the 1200 baud modem (although not optimal for refresh rates at least it will give us something to work with)
	Work on the altitude instrument (finish schematic and breadboard with new design to improve resolution)

Cheers,
Mike

[rcpilot-devs] Changes to AGW support and version check

[PK W. <pe...@wo...>]

I integrated the AGWPacket code into the Rcgs system tonight, it doesn't
work yet but it compiles clean.  I made a number of changes to Rgcs.java to
get around static vs instance troubles.  The AGW code must have an object to
use as a target.  It can't run from a static environment.  I also rewrote
the version checking to make it easier to parameterize, and set its
threshold to 1.4.2.
/peter

[rcpilot-devs] Re: F117 HUD

[Val P. <val...@ya...>]

 
 

=====


__________________________________
Do you Yahoo!?
Get better spam protection with Yahoo! Mail.
http://antispam.yahoo.com/tools

Re: [rcpilot-devs] Does anyone have a video shot from an R/C plane?

[Val P. <val...@ya...>]

Hey guys,
Sorry, I was standing on sidelines, looking at all the messages to
fly by... 
Here is one snapshot of pilot's view:
http://www.cyber-flyer.com/2003/1005_01.jpg
Attached is a picture of HUD from a computer game, F117.
Here is another example of possible HUD:
http://www.tsg1.com/images/HUD.pdf
Rick took a picture from my web site and superimposed his idea of
HUD.
Please be sure to look at:
http://www.tsg1.com/video/HUD%20Sample%20Video%203%20(Med-Res).mpg

I am giving another chance to FSK 9600 bd modem, I'll keep you
posted. If 9600 FSK can send data over the audio band - it will be an
easy solution for many problems (fast refresh rate, easy and flexible
telemetry data format).

Regards,
Val Petrov, KB1HRF, www.cyber-flyer.com



I am glad to see this project gathers momentum. 

--- "Michael J. Pawlowsky" <mi...@vi...> wrote:
> 
> 
> Well first you can get a shot at:
> 
> http://www.wimac.org/projects/mpawlowsky/drone/index.html
> 
> It's very old stuff and the technology is extremely outdated. But
> you will see where this project began and a bit of my vision of
> where I want it to go. My setup has changed quite a bit since then.
> 
> Also http://www.cyber-flyer.com/   (Val who's on this list as well)
> has quite a few shots on his site.
> 
> 
> As for a HUD....   You will find one attached.
> That is if I can.. if it gets rejected I will e-mail it directly.
> 
> 
> 
> *********** REPLY SEPARATOR  ***********
> 
> On 2/29/2004 at 3:18 PM Ian Dallas wrote:
> 
> >I'd love to get a sample HUD to use while building the
> interface...
> >
> >--ian
> 
> 

> ATTACHMENT part 2 image/jpeg name=HUD.jpeg



=====


__________________________________
Do you Yahoo!?
Get better spam protection with Yahoo! Mail.
http://antispam.yahoo.com/tools