Bugs, features, coding issues

We've had Dale Green here for the last 7 weeks, and we've had a lot of fun playing with JANUS processing and experimenting with our modem farm that is now semi-permanently deployed in the La Spezia Gulf. This has allowed us to make arbitrary tranmissions and tests of all sorts, giving us a very rapid learning curve.

Dale is now on his way back to the US, but he's left behind several key recommendations with regard to JANUS:

1) The 4-chip HFM was not a great choice, it needs to be at least 6 chips long to work well and in any case is inferior to a properly-processed 32-chip FH sequence.
2) We should be doing all our processing in baseband, not at carrier frequency.
3) We might see substantial benefits using spectral and temporal tracking through a packet (something we hope to be able to offer example code for in ver 1.0 implementations).
4) The initial concern we had that a 32-chip FH was not so Doppler tolerant as the HFM was ill-founded, a result of attempting to detect and syncrhonise using a coherent detector, whereas an incoherent detector should be used for best results.
5) The soft Viterbi and longer traceback make a big difference in decoding success rates (as we found already for the FFI data, published at UAM).
6) The 'wake-up' tones should be optional, as they consume valuable time/bandwidth if a couple of nodes are conversing, already confident that they are each awake. This is especially so because they require a guard time to allow reverberation to die out. Ver 1.0 will probably specify these tones as optional (to be used, for example, if the channel is not heavily in demand and there is a suspicion that devices may need to be woken up). As a result, decoders should not rely on the presence of these tones for acquisition or synchronisation.
7) Given that decoding starts to fall apart when the multipath duration exceeds about 1/2 a chip length, the chip length should perhaps be chosen more flexibly that at present, where it is essentially derived from the centre frequency, independently of channel properties. The current idea is to specify JANUS centre frequencies, bandwidths, and the default chip length, with the option open to use a dyadic multiple of the default chip length if the channel demands. Smart decoders will be able to both anticipate the chip length likely to be used by other nodes prior to reception, and in any case be able to determine the chip length on detection and decoding.

All these recommendations are open to discussion, of course, and ther is still time to deliberate before any get 'cast in stone' in the JANUS standard.

Ciao
John.