Question about UanTxModeFactory at uan-cw-example.cc

[Muhammad Syirajuddin Suja'i]

Dear all NS2 user,

I'm little bit confused about this code :

  mode = UanTxModeFactory::CreateMode (UanTxMode::FSK, exp.m_dataRate,
                                       exp.m_dataRate, 12000,
                                       exp.m_dataRate, 2,
                                       "Default mode");

It's from uan-cw-example.cc.

At doxygen documentation :

Parameters

type        : Modulation type.

dataRateBps : Data rate in BPS.

phyRateSps : Symbol rate in symbols per second.

cfHz        : Center frequency in Hz.

bwHz : Bandwidth in Hz.

constSize   : Modulation constellation size (2 for BPSK, 4 for QPSK).

name : Unique string name for this transmission mode.

What is the BPS mean? is it Byte per second or bit per second? If BPS = Byte per second. Why phyRateSps is set with same value with dataRateBps?

If we use binary FSK and exp.m_dataRateBps=80, the phyRateSps is supposed to be 80*8=640 symbols/sec right? Or I misunderstood something?

Thanks in advance.

[Tommaso Pecorella]

Hi,

it's in bit per second, it should be clarified.

About the other question... who said it's a binary FSK ?

Moreover, the example could be wrong :P

Cheers,

T.

[Muhammad Syirajuddin Suja'i]

Hi,

Thank you very much. :-D

[Randall Plate]

While it seems the example is correct, I had a general question along the same lines.  Why does UanTxModeFactory::CreateMode force you to set the dataRate, phyRate, and constSize all independently?  Two of the three will determine the third - unless I am misunderstanding something. I would have expected there to be checking for consistency among these parameters but there is not.  It allows me to run an example with dataRate = phyRate with constSize = 4 (which physically makes no sense).

Thanks for anyone's insights on this.

[Tommaso Pecorella]

Hi Randall,

your observation is true, a bit of consistency checking would have been good. I'm not an expert of acoustic modems (or physical layer), and the UAN module is not among the most used ns-3 modules. As a consequence it is possible that there are some questionable design choices here and there. Just check the amount of changes that there will be in Wi-Fi module from 3.24 to 3.25 (it's not yet out but it will be soon) and you'll understand how sometimes some functions have to be simplified and modified.

Anyway, I think that soon we'll have some work to do on UAN module, there are some proposed additions and code merges. As a consequence, some quirks could be removed.

if you're interested into the UAN development, just join the ns-dev mailing list.

Cheers,

T.

[Randall Plate]

Thanks so much for your thoughts on the subject.  And thanks - I'll join the ns-dev mailing list as I anticipate doing some development, particularly in the UAN module, as I work primarily in underwater networks.