A DV Dongle arrived in the post today - somewhat of a surprise as the online store of Waters and Stanton were showing it out of stock when I ordered it a few weeks back, and is still showing "Back Order" as I write this. I must have been lucky for once!
Anyway, the DV Dongle is a device that simply provides the hardware codec for AMBE, the digital audio compression standard currently used in the D-STAR DV mode. It is somewhat controversial, being a proprietary component of the otherwise open D-STAR spec. The DV Dongle isn't cheap, but it's the only product that I'm aware of that enables computer software to act as a D-STAR DV gateway to the network. Obviously, this has the upshot of allowing you to participate in D-STAR calls even when having a radio isn't too convenient (such as when I'm travelling).
A least that's the plan.
The DV Dongle fully supports the Mac, and indeed the supplied software to drive it "DV Tool" is a Java app, employing the Java audio framework, along with some native components to shuffle audio streams to and from the DV Dongle, connected to a USB port. In the installation instructions you are requested to download the latest serial drivers for the FTDI UDB-Serial bridge chipset. I had done this several weeks ago as I have other devices that use this chipset (including the Black Cat USB to CI-V interface). In any case, the software starts up and seemed to connect to the dongle hardware OK.
My problems began when trying the simple loopback audio tests with my Logitech headset (a recommended configuration). The software offers two loopback tests - one without needing the dongle (presumably just the Java audio stack), and one via the AMBE encoding/decoding hardware. My experience with either of these was not good - choppy sound with a distinct periodic transient (less than 0.5s I think), and a nasty lag. The lag with the dongle in the circuit is getting on for being between 2 and 3 seconds! In any case, the results are hardly broadcastable, and I believe I have a problem somewhere that is introducing enough latency that the audio streams are starved with the 0.5s period. I could also be sequential/blocking behaviour somewhere, where asynchronous behaviour is required. Anyway, at the moment I can only guess.
I've made a posting on the DV Dongle Yahoo discussion list, and so far I have been entreated to check that I am using the 1.6 Java stack (rather than 1.5 that apparently has issues). This has certainly been the case, though I have switched between 1.6 and 1.5 in a quest to find if that makes a difference - it did not.
So, hopefully some further ideas will come forth and I can experiment some more. I'm assuming that normal operation results in smooth/clear audio, and it looks like people are successfully using this on Macs - so I remain optimistic that this will turn out to be some irritating little piece of configuration that will eventually be a simple fix. Fingers crossed.
Saturday, June 27, 2009
Sunday, June 21, 2009
D-WARP an idea for "contact agency software" for D-STAR
I was thinking a little about software that would make D-STAR even more interesting and convenient.
D-STAR provides relatively easy to use global communications through its gateway connections between repeaters. I've just been fooling around a little for the first time with gateway routing to some repeaters back in my old stomping grounds in the UK. This works rather nicely, and although I've not used IRLP, the setting up of routing seems less messy than what I've read is required for IRLP.
I don't know how many hams care about long-distance working, but it strikes me that it would be nice to be able to see which stations were on and interested in accepting non-local calls. To that end, I can image a sort of directory of D-STAR stations as a web application, which could show stations cartographically or in a tabular form. Maybe every station could indicate whether it was just "monitoring", "inviting calls" or "actively calling". It might also be nice if every station could offer a "synopsis" and perhaps keywords/tags indicating major interests of the operator. That might facilitate more engaging hook-ups/QSOs between hams who determine they might have similar interests. Clearly, the listings could allow linking through to other station details, such as QRZ, or a station web site.
A key feature of this facility might be to auto-tune/route an attached radio when a calling operator selects a station to call. Furthermore, it would be good if the status of both stations could be automatically updated when either or both stations transmit between them. This would indicate online that the stations are in QSO and are not awaiting a call (though of course other stations might want to join them). To that end, it might also be nice if such connections could indicate online the topic of a conversation (defaulting to "general") and whether others were actively invited to participate. Obviously, when parties sign-off, their status should revert to their original indication - it would be nice if this could happen automatically, but that might simply be a time-out; and of course the user should be able to do this with a single click.
As well as soliciting contacts and showing a global state of D-STAR stations in this fashion, it might also be nice if stations actively in a QSO could be offered a 'dashboard' showing all the contributing parties, and offering extra features such as 'quick email' or 'send file'. These features could be mediated by the central server (i.e. hiding the details of the end-points), and could also be 'unlocked' for a given user by issuing a single-use pin that one station would read to another over the air.
I'm still very new to D-STAR, but a service along these lines would seem to really augment the capabilities of the D-STAR network itself. I'd be very interested in feedback on these ideas, and although I doubt there are too many people reading this blog, I'll see what people think as I meet/talk with them.
D-STAR provides relatively easy to use global communications through its gateway connections between repeaters. I've just been fooling around a little for the first time with gateway routing to some repeaters back in my old stomping grounds in the UK. This works rather nicely, and although I've not used IRLP, the setting up of routing seems less messy than what I've read is required for IRLP.
I don't know how many hams care about long-distance working, but it strikes me that it would be nice to be able to see which stations were on and interested in accepting non-local calls. To that end, I can image a sort of directory of D-STAR stations as a web application, which could show stations cartographically or in a tabular form. Maybe every station could indicate whether it was just "monitoring", "inviting calls" or "actively calling". It might also be nice if every station could offer a "synopsis" and perhaps keywords/tags indicating major interests of the operator. That might facilitate more engaging hook-ups/QSOs between hams who determine they might have similar interests. Clearly, the listings could allow linking through to other station details, such as QRZ, or a station web site.
A key feature of this facility might be to auto-tune/route an attached radio when a calling operator selects a station to call. Furthermore, it would be good if the status of both stations could be automatically updated when either or both stations transmit between them. This would indicate online that the stations are in QSO and are not awaiting a call (though of course other stations might want to join them). To that end, it might also be nice if such connections could indicate online the topic of a conversation (defaulting to "general") and whether others were actively invited to participate. Obviously, when parties sign-off, their status should revert to their original indication - it would be nice if this could happen automatically, but that might simply be a time-out; and of course the user should be able to do this with a single click.
As well as soliciting contacts and showing a global state of D-STAR stations in this fashion, it might also be nice if stations actively in a QSO could be offered a 'dashboard' showing all the contributing parties, and offering extra features such as 'quick email' or 'send file'. These features could be mediated by the central server (i.e. hiding the details of the end-points), and could also be 'unlocked' for a given user by issuing a single-use pin that one station would read to another over the air.
I'm still very new to D-STAR, but a service along these lines would seem to really augment the capabilities of the D-STAR network itself. I'd be very interested in feedback on these ideas, and although I doubt there are too many people reading this blog, I'll see what people think as I meet/talk with them.
Thursday, June 18, 2009
VisualQTH gets an airing
I demoed VisualQTH at the club this evening as part of a preparatory demo of the N1MM logging software by Dave Shipman VA7AM for the club field days (last w/e of June in the North Shore EMO, the club HQ).
We started the app up on the projector in the main meeting room - where we expect to receive visitors while the radios in the permanent club radio room are operating on a contest. Dave then made some entries into the N1MM logging software in the radio room, and these then appeared up on the display. So things went as expected :-)
We started the app up on the projector in the main meeting room - where we expect to receive visitors while the radios in the permanent club radio room are operating on a contest. Dave then made some entries into the N1MM logging software in the radio room, and these then appeared up on the display. So things went as expected :-)
Tuesday, June 16, 2009
First D-Star QSO, and more arcana
I had about an hour free today to see if yesterday's apparent successful round-trips to the ICM repeater would translate into an actual contact.
From my cursory understanding of routing configuration gleaned from various sources, I tried to cross-band on the repeater from my uplink port A to the 2m port C - I figured that fishing on 2m would most likely to find someone.
I tried a CQ call with
CQCQCQ VA7ICM A VA7ICM C
a few times and noticed a funny message "UR? VA7ICM A?" pop up when I unkeyed the mic.
Mmmm... I wonder what that message means, I thought. Maybe there's still something wrong with my routing/set up. I figured there would be something in the ID-1 manual on possible status/error messages, but on inspection... not a sausage. Icom are very light on documenting any operational aspects of the radio in the manual - it's mostly just buttons and menus that they care to comment on.
I then tried the following routing:
/VA7ICMC VA7ICM A VA7ICM G
figuring that maybe this was an alternative way to address a port C (2m) downlink on the local repeater. This flashed up another message: "RPT?", which was equally indecipherable (though strongly suggested that it didn't like something in an RPT field).
After checking that in both cases, my call was still appearing in the Recently Heard list of the repeater on the web, I resolved to try the original routine config once again, an called once more with that setting. I just wandered back to my computer once again to check that the repeater had seen me, when suddenly for the first time there was a voice emerging from the ID-1's speaker, and I just heard my call from across the room.
The caller was Gord VE7FKY, who kindly responded to my call out through 2m. Apparently I was getting out the whole time, and what I considered (still do!) the odd "UR?" message is simply some indication that nobody has responded.
Gord was kind enough to enquire whether I had completed my gateway registration correctly, indicating that you have to complete at least one extra row of information in the "Personal Information" screen of the gateway registration - something I had not done. It turns out that this extra information is essential to having the gateway accept and route your calls across repeaters, and it occurs to me that this might be why the second form of routing mentioned above resulting in the "RPT?" message.
It's not super-clear during registration that this step is required - though in retrospect I do see it mentioned various web pages. It entails adding a single space into one "initial" field, and adding your lowercase callsign as a "pcname", and finally clicking a checkbox and a button to tell the gateway software to update that row in the registration record.
Having done this, I need to test a gateway routing again, and I'm wondering about simply retrying that second form to see if it is now working (routing out via the gateway, then back into the same repeater to another port).
I've resolved to really read about and understand what the various rows are in the "Personal Information" screen, and how you use them when (unlike me currently) you do have multiple D-Star radios.
Anyway, with my first QSO properly under my belt, I can now safely assume that all the components of my 23cm setup is working satisfactorily. I'd still like to test the VSWR of the Comet CYA 1216E sometime, especially as the ID-1 got pretty hot (enough to actually smell strongly of "new electronics"!) when transmitting on the nominal 10W power. That's probably quite normal, but it would be nice to be confident that the antenna system and feed line are in the best shape they should be. That's going to be another investment in shack gear though (there are only a few SWR meters capable of covering the 23cm band) and you get to pay a pretty penny for the privilege, so it might have to wait a while!
Aside from enjoying a little ragchewing on my newly commissioned toy, I'm gradually accreting an agenda for other things to play with on D-Star. The DD mode is a must-try sometime very soon, but I'm also reading about various tools that make use of the "spare" 1200 bps bandwidth in the DV mode (for text messaging and maybe other purposes - a BBS anyone?).
From my cursory understanding of routing configuration gleaned from various sources, I tried to cross-band on the repeater from my uplink port A to the 2m port C - I figured that fishing on 2m would most likely to find someone.
I tried a CQ call with
CQCQCQ VA7ICM A VA7ICM C
a few times and noticed a funny message "UR? VA7ICM A?" pop up when I unkeyed the mic.
Mmmm... I wonder what that message means, I thought. Maybe there's still something wrong with my routing/set up. I figured there would be something in the ID-1 manual on possible status/error messages, but on inspection... not a sausage. Icom are very light on documenting any operational aspects of the radio in the manual - it's mostly just buttons and menus that they care to comment on.
I then tried the following routing:
/VA7ICMC VA7ICM A VA7ICM G
figuring that maybe this was an alternative way to address a port C (2m) downlink on the local repeater. This flashed up another message: "RPT?", which was equally indecipherable (though strongly suggested that it didn't like something in an RPT field).
After checking that in both cases, my call was still appearing in the Recently Heard list of the repeater on the web, I resolved to try the original routine config once again, an called once more with that setting. I just wandered back to my computer once again to check that the repeater had seen me, when suddenly for the first time there was a voice emerging from the ID-1's speaker, and I just heard my call from across the room.
The caller was Gord VE7FKY, who kindly responded to my call out through 2m. Apparently I was getting out the whole time, and what I considered (still do!) the odd "UR?" message is simply some indication that nobody has responded.
Gord was kind enough to enquire whether I had completed my gateway registration correctly, indicating that you have to complete at least one extra row of information in the "Personal Information" screen of the gateway registration - something I had not done. It turns out that this extra information is essential to having the gateway accept and route your calls across repeaters, and it occurs to me that this might be why the second form of routing mentioned above resulting in the "RPT?" message.
It's not super-clear during registration that this step is required - though in retrospect I do see it mentioned various web pages. It entails adding a single space into one "initial" field, and adding your lowercase callsign as a "pcname", and finally clicking a checkbox and a button to tell the gateway software to update that row in the registration record.
Having done this, I need to test a gateway routing again, and I'm wondering about simply retrying that second form to see if it is now working (routing out via the gateway, then back into the same repeater to another port).
I've resolved to really read about and understand what the various rows are in the "Personal Information" screen, and how you use them when (unlike me currently) you do have multiple D-Star radios.
Anyway, with my first QSO properly under my belt, I can now safely assume that all the components of my 23cm setup is working satisfactorily. I'd still like to test the VSWR of the Comet CYA 1216E sometime, especially as the ID-1 got pretty hot (enough to actually smell strongly of "new electronics"!) when transmitting on the nominal 10W power. That's probably quite normal, but it would be nice to be confident that the antenna system and feed line are in the best shape they should be. That's going to be another investment in shack gear though (there are only a few SWR meters capable of covering the 23cm band) and you get to pay a pretty penny for the privilege, so it might have to wait a while!
Aside from enjoying a little ragchewing on my newly commissioned toy, I'm gradually accreting an agenda for other things to play with on D-Star. The DD mode is a must-try sometime very soon, but I'm also reading about various tools that make use of the "spare" 1200 bps bandwidth in the DV mode (for text messaging and maybe other purposes - a BBS anyone?).
D-Star lift off!
OK, I just tested my set up into VA7ICM using the trick of setting the local gateway for RPT2 routing, but with the CQCQCQ UR Call. Everything works hunky-dory... at least I get back the error message from VA7ICM saying it can't find the call CQCQCQ.
So it looks like I'm in business, and more to the point that my handiwork in getting the yagi up and pointing in the general direction, with the feed line in good shape, is all OK.
I've tried both 10W and 1W (low power), and seem to have no problem being heard/understood by the repeater, at least for this minimal handshake. It would be cool if you could get the gateway to respond with a signal/quality metric, perhaps displaying this with your call sign in the available online logs (last heard lists), that way I could ascertain whether 1W is genuinely sufficient for reliable communication with the repeater, or whether it is borderline.
.....
I've just tried VE7RAG, which is well off-axis of my beam, and still managed to wake up this repeater too on 1W! So, I'm a pretty happy bunny. When I get time I might see if I can wake up VE7VIC too. I very much doubt I can make it into that repeater as it lies some 61.33 statute miles to the SSW. This is well beyond the stated 20mi range claimed on the repeater. I don't know how this is computed, but it's noticeably less than the 40mi claimed for both VE7RAG and VA7ICM.
So it looks like I'm in business, and more to the point that my handiwork in getting the yagi up and pointing in the general direction, with the feed line in good shape, is all OK.
I've tried both 10W and 1W (low power), and seem to have no problem being heard/understood by the repeater, at least for this minimal handshake. It would be cool if you could get the gateway to respond with a signal/quality metric, perhaps displaying this with your call sign in the available online logs (last heard lists), that way I could ascertain whether 1W is genuinely sufficient for reliable communication with the repeater, or whether it is borderline.
.....
I've just tried VE7RAG, which is well off-axis of my beam, and still managed to wake up this repeater too on 1W! So, I'm a pretty happy bunny. When I get time I might see if I can wake up VE7VIC too. I very much doubt I can make it into that repeater as it lies some 61.33 statute miles to the SSW. This is well beyond the stated 20mi range claimed on the repeater. I don't know how this is computed, but it's noticeably less than the 40mi claimed for both VE7RAG and VA7ICM.
More D-Star learnings
Pete (AE5PL) replied to a few questions I posted up on the
DStarUsers.org forum concerning some outstanding questions I had.
Two items of particular interest:
1. I had asked whether there was a way to test D-Star access into a repeater without bugging anyone for a radio check.
Pete said:
Sure, place CQCQCQ in URCALL, VA7ICM A in RPT1, and VA7ICM G in RPT2. You should see VA7ICM G respond back that it doesn't know CQCQCQ (you will see VA7ICM G show up on the front display).
... pretty handy!
2. I asked about gateway registration on repeaters, considering I had registered on one repeater but am likely to be using another for most activity. I was concerned as to whether you should be registered on the gateway you were actually going to be using as a 'home'. Pete's response was that you only need register on one gateway (and indeed should not be registered multiple times), and that registration on any one gateway is sufficient to use all gateways.
Considering I have yet to raise the admins of VA7ICM with this same question, I'm pretty glad my VE7RAG registration (which went through in under a day) will work anywhere.
Tomorrow I intend giving my ID-1 its first airing with an attempt to wake up the VA7ICM repeater in the manner described in (1). If I get any sign of life from the repeater on its port A, then I'll try a CQ call onto its 2m port to see if I can magic up a real QSO!
DStarUsers.org forum concerning some outstanding questions I had.
Two items of particular interest:
1. I had asked whether there was a way to test D-Star access into a repeater without bugging anyone for a radio check.
Pete said:
Sure, place CQCQCQ in URCALL, VA7ICM A in RPT1, and VA7ICM G in RPT2. You should see VA7ICM G respond back that it doesn't know CQCQCQ (you will see VA7ICM G show up on the front display).
... pretty handy!
2. I asked about gateway registration on repeaters, considering I had registered on one repeater but am likely to be using another for most activity. I was concerned as to whether you should be registered on the gateway you were actually going to be using as a 'home'. Pete's response was that you only need register on one gateway (and indeed should not be registered multiple times), and that registration on any one gateway is sufficient to use all gateways.
Considering I have yet to raise the admins of VA7ICM with this same question, I'm pretty glad my VE7RAG registration (which went through in under a day) will work anywhere.
Tomorrow I intend giving my ID-1 its first airing with an attempt to wake up the VA7ICM repeater in the manner described in (1). If I get any sign of life from the repeater on its port A, then I'll try a CQ call onto its 2m port to see if I can magic up a real QSO!
Sunday, June 14, 2009
23 cm beam to VA7ICM
My 23cm capability got real today (theoretically) with the addition of a real antenna to replace the indoor mobile antenna I had hooked up as a temporary measure. A Comet CYA 1216E is now gracing my tower, pointed in the general direction of the VA7ICM D-Star repeater in Surrey.
The rough direction to point was determined from the location of the repeater available on-line:
VA7ICM location
Using this information, I was able to plot a line between my QTH and VA7ICM using Google Earth, and ascertain the direction to point in according to visible landmarks:
As usual bumbling around up the tower was 'fun'. I especially like the bit where you are holding the antenna, with an awkward 42' of LMR-400 coiled out the back, and trying to get the U bolt/nuts aligned and tightened without slipping anything or dropping anything (least of all oneself).
Anyway, I survived :-), and in theory the antenna is aimed at the right spot for VA7ICM. In practice I may have to wait to find out if everything is working until I'm properly registered on VA7ICM and unregistered from VA7RAG (which I registered with before realising that VA7ICM is probably a better choice in terms of line of sight, even if its a little more distant). I've been waiting for a response from the VA7ICM admin for a few days, so hopefully something will be forthcoming soon.
Here are a few pictures of the new tower denizen:
The rough direction to point was determined from the location of the repeater available on-line:
VA7ICM location
Using this information, I was able to plot a line between my QTH and VA7ICM using Google Earth, and ascertain the direction to point in according to visible landmarks:
As usual bumbling around up the tower was 'fun'. I especially like the bit where you are holding the antenna, with an awkward 42' of LMR-400 coiled out the back, and trying to get the U bolt/nuts aligned and tightened without slipping anything or dropping anything (least of all oneself).
Anyway, I survived :-), and in theory the antenna is aimed at the right spot for VA7ICM. In practice I may have to wait to find out if everything is working until I'm properly registered on VA7ICM and unregistered from VA7RAG (which I registered with before realising that VA7ICM is probably a better choice in terms of line of sight, even if its a little more distant). I've been waiting for a response from the VA7ICM admin for a few days, so hopefully something will be forthcoming soon.
Here are a few pictures of the new tower denizen:
Subscribe to:
Posts (Atom)
