To All,
1. I got flwrap from the alpha page.
2. OK on it being a compressed file and not encrypted.
A. MARS is directed by the Department of Defense not the FCC.
The DOD says we do not use encryption in MARS unless the client's
message is encrypted. Someone would have to run FLWRAP through the DOD for
authorisation for MARS use.
3. Having the message sent in plain language is what we need.
A. All MARS messages are text files.
B. If for some reason we need to send any other type of file we
would probably use EasyPal.
C. .csv files could also be sent by fldigi.
4. Trying to get all MARS members to use fldigi would require
an edict from the Chief's of each MARS service to declare it the
only software to use. Until that time we have MixW, DM-780 and
others in use. Most of our transmissions are in MT-63 1K or 2K
long interleaf. Occasionally we use Olivia.
A. FLWRAP or WRAP will work with the other software but they
don't have the drag and drop properties of fldigi.
B. Getting everyone to use FLWRAP would also require an edict.
C. The best and easiest way to get everyone to use it is to make
it as simple and universal as possible.
D. In a MARS net there may be 15 or 20 members getting the
traffic, unlike an EMCOMM situation in a non-MARS net where
the stations would probably be one on one. As an EC and EMA
radio officer for my county I would use the FLWRAP.
5. The old WRAP did not have any objections from the upper
echelon that I am aware of; even though it added several extra
lines to the message (not military format).
A. If the old WRAP will work, that's all we need.
6. How much time is saved by compressing a 500 byte text file?
A. MARS has the bandwidth to use MT63-2K; if there are faster modes
we would like to try them.
7. It would be tough to teach our older MARS members to use command
line switches; even if I could pry them away from MixW that they paid $50 for.
8. Where can I send a screen shot of how I set up fldigi and the message
folders? I think if you try it you will find it very fast and efficient.
Thanks for all the suggestions and the help, I really appreciate it.
On Sat, Dec 19, 2009 at 10:41 AM, w1hkj <[email protected]> wrote:
> Don, I've opened this discussion up to a larger audience since the
> resolution will effect many flwrap users.
>
> Donald Kemp wrote:
>
> Dave,
> Too late, I uninstalled and reinstalled flwrap from your site.
> No problem, didn't take long.
> I did what you suggested and it did work OK.
> I installed the flwrap on the other guy's computer
> and I am reasonably sure he used flwrap because the old
> WRAP was not installed. His fldigi did see the flwrap file
> and saveed it to the correct directory but he got the same
> encripted file when he dropped it through flwrap.
>
> You must have installed the wrap executable on the regular web site and not
> the alpha page Don. I just repeated the experiment with dropping the file
> onto "wrap-1.0" which of course only yielded the compressed file and not the
> original. On Linux this is a no brainer as the user can then uncompress
> using the lzma compression tool. Some of the windows compression tools
> might also work. That makes me quite certain that the two ends are not
> using compatible versions of flwrap. The confusion probably comes from my
> reusing the wrap icon for flwrap.
>
> We do not use the desktop icons, we install it into the quick
> launch bar. Maybe that has something to do with it.
>
> I've never tried it that way, but be advised that the program was designed
> for use with a desktop icon launcher.
>
> We have a directory for traffic to send and it has a flwrap shortcut in it
> and it resids at the lower left of fldigi.
> We then have the flwrap directory at the upper left of fldigi also
> with a shortcut of flwrap in it.
> When wrapped traffic comes in it appears in the flwrap directory;
> it can then be dropped into that shortcut and the native file should appear.
> This new file can be dragged into the send directory or into the
> fldigi send buffer
> is needed.
> It all works very quickly and efficiently.
> We will try again.
>
> Sounds like you have a process that works for you.
>
> However; having a file being transmitted as an incripted file
> will not work for MARS.
>
> Bad word ... encrypt ... a no no as far as the FCC is concerned. The file
> is not encrypted, it is compressed using public domain compression methods.
>
> As a traffic rep, I would have to send the file twice,
> once as a WRAP file and once as straight text. This only makes for
> longer traffic
> runs and wasts net time. Is it possible to make flwrap show normal text?
>
> Why? When all of the users are using the same software would they not all
> have the correct flwrap?
>
> Will the old WRAP still work with the current Alpha version of fldigi?
>
> Yes, but it will be deprecated by flwrap.
>
> What you really want is either the original wrap behavior or a software
> switch that forces all data to be uncompressed if it originated as plain
> ASCII text. Note that all images, binary data files (including MS Word
> ".doc" files) would still require compression and encoding using base64.
> Because there are no "configuration" files for flwrap it would be necessary
> to make that switch a command line switch. On Windows XP/Vista/Win7 that
> would require that the launcher properties be changed to include something
> like:
>
> Target: "C:\Program Files\flwrap-1.0.2\flwrap.exe" --nocomp
>
> I just checked on Vista and the Quick Launch bar also allows you to change
> the properties in this manner.
>
> It might be better to make the default without compression, since many users
> seem to have minimal systems administration knowledge in the MS world. Then
> the launch target properties would be:
>
> Target: "C:\Program Files\flwrap-1.0.2\flwrap.exe" --usecomp
>
> The purpose of compressing all files was to reduce the transmission time.
> Files transferred using flwrap contain data which must be verified. If you
> are simply eyeballing the internal contents of the wrapped file you are
> defeating its purpose. Why waste time with the headers etc. Just transmit
> the original file and accept propagation errors. If the data must be intact
> and verifiable then it makes no difference whether you can read the data
> during transmission or not. If it cannot be unwrapped correctly then the
> data is useless. A good example might be a spreadsheet in comma separated
> value (.CSV) format that contains numeric data. How would you verify this
> data without the wrap technology. You would either have to repeat the file
> transmission several times and then do voting, or the operators would have
> to verify item-by-item.
>
> Dave, W1HKJ
>
>
> _______________________________________________
> fldigi-alpha mailing list
> [email protected]
> https://lists.berlios.de/mailman/listinfo/fldigi-alpha
>
>
--
73,
Don, NN8B / NNN0VJM OH
_______________________________________________
fldigi-alpha mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/fldigi-alpha
