ORCA DIGITAL NET

ORCA DIGITAL NET, Report 20jan15
Check-ins: 11
Traffic: 8
Keyboard: 1
Monitor: 2
Stations:
KI6RIT Nick
KJ6UPE Danon
WA6NBG Don
KW6JIM Jim
KB6NN Howard
W6IES Peter
KA6ULG Bob
K7IFG Ken
W7ZAP Mindy
N6ZZO Kai
K7KY Doug NCS

We had a great turnout tonight. It’s really gratifying to have so many seasoned digital operators in the net. We’ve all learned a lot since we began and we’re gaining experienced Amateurs who enrich the learning environment. As always, your observations and suggestions are welcome. And, I don’t have an email address for all members. If you know someone I’m missing or would like to read-the-mail, please send me their address: k7ky@orcadigitalnet.com. If you want off this list, let me know.

Low bands in winter are a challenge. Again we had a difficult time at 3.955voice. When we returned following digital traffic, only a couple stations could communicate directly. We did much better on 3.595data. This brings my thoughts back to experimenting with a digital-only net format.

It’s hard to believe but I crunched the same callsigns again this week. I have backup files everywhere and they all had errors. I think I’ve rooted them out, but I hesitate to say for sure. Anyway, my sincere apology for messing up your callsign. Conditions weren’t great on 3.595, but MFSK32 is pretty robust and we didn’t have too much trouble. Again this week, I was unable to copy the net log. My fldigi crashed twice. I’m using a Beta version, so that may explain the issue.

Again this week, we didn’t complete an flamp exchange. Mindy & I sent & received two files before the net. We interrupted the signal enough to drop a couple packets and the REPORT and RESEND worked properly. But on the net, we were unable to get a REPORT for the missing packets. Although I thought I was prepared to send from flamp, I’d left an incoming file in flamp and that may have prevented it from sending, I don’t know yet. We’ll keep working with flamp; it will be important for long files. Along with that thought, please announce compressed files before sending until we are all familiar with compression. Compressed files cannot be read in the receive window. It the file fails checksum we can still read an uncompressed message.

Speaking of long files, we want to be mindful about the length of our practice files. Keep in mind that the balance of the net is idle/copying while you xmit. Some files are important to the net for content. Don WA6NBG generates the Humboldt Co Bulletin every week and there are occasional announcements that take 3-5min to send. We get more practice with short files than long. Some stations prepare two messages before net so they can select depending on the length of preceding files.

Last week I contacted Dave W1HKJ the fldigi developer. He’s very user friendly and agreed to develop a couple new features for us. I asked Dave to add a Color / B/W switch to the macro VIDEO command and make some new commands to enable us to quickly print our ID on the waterfall and return fldigi to net-configuration directly with one button. I just downloaded the 2nd Beta version of fldigi and so far, the new features and commands seem to be working well.

We will be able to send greyscale or color images from a macro command and more importantly, print our ID on the waterfall quickly w/o a carrier tail. He has created commands to return fldigi to net configuration after IDing. When we know the new version is solid, I’ll distribute the information you’ll need to use the new features. I’ll also distribute the macro file I use for the net. If you should become an alternate NCS, it will jump-start building your own macro file. Or, you can delete the buttons you don’t need and modify the others to your operating style.

Dave W1HKJ has been great to work with. It’s not often you can contact an applications developer and effect the product. Dave has passed our macro project on to the NBEMS group in PA, probably the foremost NBEMS group in the US today. When I thanked Dave for working with me, he said it’s how he prefers to work. Here’s a snip of our email:

————–
> Thanks again, Dave. It’s not often users can interact with the
> programmer and effect the app. Fldigi is excellent! 73 Doug K7KY

It is my preferred method of development and it’s called RAD, Rapid Application Development. It requires that the feature requester and the coder become a team. Each is as important as the other.

Dave
——————-
Nice, feeling as important as the programmer! Hope to see you all next week. Think about trying the single frequency net again, at least during winter band conditions. I think we can make it work; the new ID feature may improve digital check-in.   73 Doug K7KY