1.2 GHz HSMM with the Icom ID-1

Back in June 2004 we inquired about Icom's 1.2 GHz ID-1 D-Star solution for ham radio voice and data communications. We were fortunate enough to be able to evaluate it for a few months.

Our short documentation is located at:

http://www.qsl.net/n9zia/dstar-evaluation/

You can also read the Wisconsin Amateur Packet Radio review here:
http://www.qsl.net/kb9mwr/wapr/0204.html

We were most interested in the data performance and networking ability of the D-STAR system. The only radio that can do any significant data transfer is the 1.2 GHz ID-1. It's listed with a (theoretical value) transmission speed of 128 kbs. We clocked an effective TCP/IP throughput of 90 Kbs. Perfectly understandable considering protocol overheads.

We didn't have a lot of time to mess with it. Our initial path was a 4 mile hop, but that was just on the fringe due to the Packers stadium in the middle. We could communicate using the digital voice mode and analog FM, but not the digital data. A few more feet of height might have done it. We were at 60 feet at the remote end, and 40 at the other.

So we opted to test the data performance on a much shorter path with another local.

The lesson learned is even at 10 watts on 1.2 GHz, verses the 1 watt or less on 900 MHz or 2.4 GHz, microwave path loss doesn't change much.

So in our case for much, much less money we can accomplish the same paths at even higher speeds using other hardware. What would be interesting is to see how well the ID-1 would work mobile. I do believe it would work quite well for this compared to the alternatives.

{edit} Reports indicate that it takes a very solid signal into the Access Point/DD system to work well. And works good over a large area when non-moving, but motion/multipath tears it up. A continuous ping by with a 1.2 GHz radio would start working at very stop light, and stop as soon as was moving.

After having looked at the various documentation, the Digital Data (DD) mode of the 1.2 GHz Icom ID-1 is a rather strange design.

There is reason for concern on that the amount of overhead is huge (D-STAR header + Ethernet header + IP header), and that the FEC as implemented is a bit strange (why does it only apply to the D-STAR header, and not the Ethernet frame?). Further the protocol has no real mention of channel access concerns (collision detection, avoidance, etc). It really looks to me like DV with ethernet frames stuffed into the payload section (i.e. maybe it was somewhat of an afterthought).

All the DD mode appears to do is forward ethernet frames around. On its own, it does not do any acknowledgment/handshaking. This is all left to the upper-layer protocols (i.e. TCP).

It appears that if a collision happens then the DD packet is just lost, and there's no really mechanism to avoid collisions at the DD layer, either. It's up to the higher-layer protocol to do anything about it.

So you really have no indicator of channel quality when using it. The lack of this sort of thing seems like a major oversight. It looks like packet radio done badly, although with better speeds. If it were introduced 15 to 20 years ago we would have hailed it as the savior of packet radio, but now it looks like a poor imitation of WiFi.

To further, it doesn't help most of what you will read on the other D-Star Yahoo groups shows that the ID-1 isn't being used with good RF engineering practice leading to poor results.