Serial init sequence for 1.06

[dirkx]

Does the 1.06 firmware need a specific wake-up sequence on the serial
port? I'd expect it give at least a peep with below.

But have total silence (on MacOSX lion with the official/normal
Silicon Labs 2.9.0d1.

Thanks,

Dw


#include <fcntl.h>
#include <stdio.h>
#include <termios.h>
#include <errno.h>
#include <unistd.h>
#include <string.h>

int main(int argc, char **argv)
{
char *cpath = "/dev/cu.SLAB_USBtoUART";
struct termios termattr;
char buff[1024];
int fd, l;

if ((fd = open(cpath, O_RDWR | O_NOCTTY)) < 0) {
perror("open()");
return 1;
};

if (tcgetattr(fd, &termattr) < 0) {
perror("tcgetattr()");
return 1;
};

termattr.c_cflag &= ~(CSIZE | PARENB | PARODD | CSTOPB);
//termattr.c_cflag &= ~(CLOCAL | CCTS_OFLOW | CRTSCTS | CRTS_IFLOW
| MDMBUF | HUPCL);
termattr.c_cflag |= CS8;
//termattr.c_cflag |= CLOCAL;

//termattr.c_iflag &= ~(IXON | IXOFF | IGNBRK);

cfsetispeed(&termattr, B2400);
cfsetospeed(&termattr, B2400);

if ((tcsetattr(fd, TCSANOW, &termattr)) < 0) {
perror("tcsetattr()");
return 1;
};

sprintf(buff, "#%cC0", 4);

errno = 0;
l = write(fd, buff, 4);
if (l < 0)
perror("Write(4) failed");

printf("write: %d == 4\n", l);

errno = 0;
l = read(fd, buff, sizeof(buff));
if (l < 0)
perror("Read failed");

printf("read=%d\n", l);
if (1 && l > 0) {
char *p = buff;
while (l--) {
unsigned char c = *p++;
if (c > 31 && c < 128)
printf("%c", c);
else
printf("<%02x>", c);
if (!(l % 8))
printf("\n");
};
}
close(fd);
return 0;
}

[Ariel Rocholl]

Hi,

I'm glad to see some experiments in MacOS.

You are correct you need a starting sequence. By default RF Explorer will not dump data to RS232 circuitry to limit current consumption except the other end start a talk. After that point RF Explorer knows there is someone interested in hearing data and so it will start dumping data out.

To start the sequence, send a Request_Config command from Mac to RFE. RFE will answer back with configuration data Current_Setup and then Current_Config.

After that you will get dBm reads back as long as the Spectrum Analyzer screen is active in RFE. So be prepared to capture Sweep_data in some sort of continuous loop.

You may use the C# code as an starting point, even if you are not very familiar with C# this is straight forward code for a C developer:

* Check file MainForm.cs

* When the COM port is opened, it reacts in function

private void ConnectPort(string PortName)

* Right inside ConnectPort() you can see a call to

AskConfigData();

* If you check on this function, you will see it does a Request_Config as described above (Sends a "C0" to RFE).

I see you are using 2400bps, make sure you configured your RFE in the same way, otherwise you won't get any compatible packet in the Mac.

Let me know if you have any question, I will be willing to help.

Thanks.
Ariel

[dirkx]

Ok - so that is why in the above snippet I am sending exactly 4 bytes
('#', 4, 'C', '0'):

sprintf(buff, "#%cC0", 4);

as the first and only thing. Both devices set to 2400 as I thought
that was most reliable. If I do that - I get no reply.

If I sent it 2-3 times - the screen on the RFExplorer groups blank
(until I power cycle it).

Anything else I can try ? I take it that the C0 is not terminated by
anything - and that windows does not do something special ?

The device is known to work with a PC (and on the latest firmware) ?

Dw

[aroc...@gmail.com]

You are right, I didn't see that. Can you debug/check the "#[4]C0" string is
what you are actually sending on? To minimize a potential RS232 sync
problem, try also sending a larger string with garbage at the end such as
"#[4]C0xxxxx". The "x" garbage will be ignored as goes beyond the 4 bytes
size expected, but will help to fill it up the RS232 buffer and force a
flush better.

The string command doesn't need to be terminated, that is why it includes
the size (4 bytes for this cmd) to optimize interrupt mgmt. inside the PIC24
MCU.

Blank screen is a rare but known bug, fixed in v1.07 firmware. I would
suggest to upgrade to v1.07 and try again.

Thanks
Ariel Rocholl

[Dirk-Willem van Gulik]

On 9 okt. 2011, at 23:52, <aroc...@gmail.com> <aroc...@gmail.com> wrote:

> You are right, I didn't see that. Can you debug/check the "#[4]C0" string is
> what you are actually sending on? To minimize a potential RS232 sync
> problem, try also sending a larger string with garbage at the end such as
> "#[4]C0xxxxx". The "x" garbage will be ignored as goes beyond the 4 bytes
> size expected, but will help to fill it up the RS232 buffer and force a
> flush better.

Ok - no change. Too many XXX's does not matter - more #[4]C0's blank the device.

> The string command doesn't need to be terminated, that is why it includes
> the size (4 bytes for this cmd) to optimize interrupt mgmt. inside the PIC24
> MCU.

Good.

> Blank screen is a rare but known bug, fixed in v1.07 firmware. I would
> suggest to upgrade to v1.07 and try again.

Am at 1.07 7-sep-2011 - which blanks after some 4 to 16 #C0's.

Wondering if I should open up the device and tap the wires to the main CPU on the board to see what is passed really by windows and by me.

Dw

[Ariel Rocholl]

That is interesting, I would bet the RFExplorer is not getting what it should get. It may be easier to work with a debug tracecode version that echoes what it gets from your RS232 connection, that may be way less intrusive than taking the unit apart for sniffing. Let me know if you want to try that, I can prepare a firmware with echo in a couple of days for you to test.

Another option is to use some of the RS232 sniffer software available out there, not sure for MacOS but for Windows I used a couple of them in the past with good results for some applications, but I don't recall the specific product name.

As for the blank screen, that is not expected nor I could reproduce it anymore with the fix in place. Which screen was the RFExplorer on when you communicate and get the blank on it?

Thanks
Ariel

[Dirk-Willem van Gulik]

Got a step further

- Soldered 2 wires to the TTL of RX/TX (there where some nice VIA's ideal for this).

- And tapped those with a Logic (http://www.saleae.com/logic/). Resulting files
are https://pikmeer.webweaving.org/86a54f11d80e4182f7557a22296f6116ba8e2c30/.

You can download the visualizer for free at saleae.com - attach the async serial
decoder to trace 1 and 2 with 'auto baud'.

- Confirmed that the Windows PC version and my code are sending the exact
same string.

Results of this suggest that on firmware 1.06 and 1.07 both:

- Regardless of setting in the menu on the RFE - 2k4/500k (and even if they are
confirmed persisting over a on/off) - the device is in 500k.

-> PC app does not want to talk to it in 2k4 (trace 2400.logicdata shows no
return traffic).

-> While talking to it in 500k works (trace 500k.logicdata) even though screen
confirms 2400.

-> Toggling remote screen a few time causes a screen blanking when talking
proper 2400.

So my first issue seems to be - firmware 1.06 and 1.07 do not actually talk 2400 baud ? Could that be ?

Secondly - I found that MacOS and Linux cannot talk 500k with the default Silicon Lab drive. The cap seems to be B230400.

Would there be any way for you to check if 2400 can be made to work and/or if we can have 115k2 and 230k4 added ?

Thanks,

Dw

[Dirk-Willem van Gulik]

Found a more low level method in IOKit to bypass the limit on OSX. Not yet on linux. Now struggling with stability.

Dw

[Ariel Rocholl]

Thanks for all this useful data, I will review it and get back to you in a day or two.

I'm pretty sure the 2400bps mode works but will retest and send you more details. Also note there are RS232 commands available to change the baud speed on the fly: you basically start in 2400bps and then move to 56K or any other supported standard speed.

Best,
Ariel

[dirkx]

Ok - meanwhile noticed that when I sent a #C<4>0 I get back

2011-10-11 11:36:07.387 fred[8405:707] '#C2-M:003,255,01.07<crlf>'

which I can decode happily

2011-10-11 11:36:07.388 fred[8405:707] Mainboard WSUB1GM, expansion
card: not fitted, firmware: 01.07

but then with 1.07 firmware the 2 next lines are (after which I see
lovely $S's):

2011-10-11 11:36:07.395 fred[8405:707] '#C2-M:
0515000,0892857,-050,-120,0112,0,000,0240000,0960000,0100000<crlf>
2011-10-11 11:36:07.401 fred[8405:707] '#C2-M:
0515000,0892857,-050,-120,0112,0,000,0240000,0960000,0100000<crlf>

What are these ? Should this not be C2-F ?

Dw.

[Ariel Rocholl]

Hi,

You are correct, the 2400bps mode was not working from the CONFIG MENU. It was from programmatic control, but that doesn't help if you have to start in 500K mode and that is not available.

Thanks for catching and reporting this, I will make sure it is being tested manually moving forward for every release (not only programmatically).

I guess part of the noise you get is because of baud speed problem. The strings you should get after a #[4]C0 are something like:

#C2-M:000,255,01.07
#C2-F:0430000,0089285,-020,-120,0112,0,000,0430000,0440000,0010000
#C2-F:0430000,0089285,-020,-120,0112,0,000,0430000,0440000,0010000

Last full config line is always repeated, but it is a C2-F not a C2-M. Again this may be from a mistmatch in baud speed. I am sending you privately instructions to get a 2400bps fixed test version with debugging capabilities so you can work this out easily.

Thanks
Ariel

[Dirk-Willem van Gulik]

On the $S reply - I see

if ((sLine.Substring(0,2)=="$S") && (m_fStartFrequencyMHZ > 100.0))
{
if (!m_bHoldMode && m_nDataIndex < m_nTotalBufferSize)
{
for (int nInd = 0; nInd < m_nFreqSpectrumSteps; nInd++)
{
byte nVal = Convert.ToByte(sLine[2 + nInd]);
float fVal = nVal / -2.0f;

in the original code. But looking at the raw data - it seems that the first byte after the $S is always the same (112) -- while there are indeed
m_nFreqSpectrumSteps bytes following.

Now could it be that the format has changed since the PC code - and the value behind $S is in fact the length ?

Thanks,

Dw.

[Ariel Rocholl]

Note you are looking at timer_receive_Tick() a preprocessed string. If you look into the receiving thread ReceiveThreadfunc(), you can see raw data processing

                            if ((strReceived.Length > 2) && (strReceived[1] == 'S') && ((byte)strReceived[2] == m_nFreqSpectrumSteps))
                            {
                                if (strReceived.Length >= (3 + m_nFreqSpectrumSteps + 2))
                                {
                                    string sNewLine = "$S" + strReceived.Substring(3, m_nFreqSpectrumSteps);
                                    string sLeftOver = strReceived.Substring(3 + m_nFreqSpectrumSteps + 2);
                                    strReceived = sLeftOver;
                                    Monitor.Enter(m_arrReceivedStrings);
                                    m_arrReceivedStrings.Enqueue(sNewLine);
                                    Monitor.Exit(m_arrReceivedStrings);
                                }
                            }

In this string the 3rd byte (corresponding to 112 in a standard SA screen) is lost as the code already checked it was of the expected size (m_nFreqSpectrumSteps == 112).

Therefore the $S command in the wiki, what you get in your test and the PC client code are all consistent.

Regards,
Ariel

[Dirk-Willem van Gulik]

Ok - with your interim version I got things working wonderfully - a very rudimentary draft is at:

https://github.com/dirkx/iRF-Explorer

Screenshots below for those who are into that. Feel free to hack on it - plenty to do.

Thanks,

Dw.

PS: and some questions: https://github.com/dirkx/iRF-Explorer/blob/master/iRfExplorer/iRFExplorer/TODO.txt

[dirkx]

Hmm - google groups does not take kindly to images -- uploaded at

http://dirkx.github.com/iRF-Explorer/

Dw.

[Ariel Rocholl]

Great job dirkx!

I will publish a link on the website so people know. Is it limited to 2400bps so far or works at other baudrates?

Will be answering your questions in the next days and will release a public fixed version for the 2400bps.

Thanks
Ariel

[Dirk-Willem van Gulik]

On 15 okt. 2011, at 20:29, Ariel Rocholl wrote:

> I will publish a link on the website so people know. Is it limited to 2400bps so far or works at other baud rates?

Strangely enough - with your newer firmware it seems to work at 2400 and 500k. And reliably so - can run the LCD for hours without narly a glitch.

With the older version I am getting somewhat erratic results - including the CF-M v.s. CF-F (which is surprisingly consistent).

Do note though that the OSX drivers for the USB serial may not 'officially' support 500k. Not sure.

Dw

[Ariel Rocholl]

>> Strangely enough - with your newer firmware it seems to work at 2400 and 500k. And reliably so - can run the LCD for hours without narly a glitch.

That is surprising as the only change added was to enable a baudrate switch. I cannot possible see how that could resolve the weird C2-M / F stuff.

Anyway, nice to know the new version worked, I will be making it public in a day or two.

Thanks
Ariel

[Dirk-WIllem van Gulik]

On 17 Oct 2011, at 17:48, Ariel Rocholl wrote:

> >> Strangely enough - with your newer firmware it seems to work at 2400 and 500k. And reliably so - can run the LCD for hours without narly a glitch.
>
> That is surprising as the only change added was to enable a baudrate switch. I cannot possible see how that could resolve the weird C2-M / F stuff.

Ok - so in the end I resorted to soldering two wires to the TTL and using a Logic from saleae.com - so I could capture the data directly.

> Anyway, nice to know the new version worked, I will be making it public in a day or two.

Lovely!

Dw