I uploaded a new tinySA.zip with the new exe.
Improvements:
- Logging is better split in lines making it easier to understand what is happening
- log of {} is now as {} i.s.o b/e
--
HBTE Files section:?/g/HBTE/files
Erik, PD0EK

Thanks Erik,
Unfortunately new version gives same results for me.

One think I have noticed is when I unplug/plug the USB cable, then open tinySA.exe I get a pop up error
window that says "no sweeper found".? I say ok, then it pops up the PortSelector window with my COM5
already highlighted.. I say ok and the main window pops up with a noise graph (like it is in Mockup mode?).
If I push Run, the tx/rx leds on nano do blink, power supply does change current but log window doesn't
show any communication.
I am thinking it might be something at startup.. With Nano code, the info comes out immediately, maybe it
should wait for the .exe to ask for it?

I see in the .ino in setup:

? Serial.begin(115200); // 115200
#if defined(ARDUINO_ARCH_SAMD)
//? while(!SerialUSB); // Uncomment this line if you want the Arduino to wait with starting till the serial monitor is activated, usefull when debugging
#endif

So I have tried putting in:
?delay(10000);? //gaw experiment
OR
? while(? Serial.available() == 0)? //gaw exp

BUT still nothing...
Thanks and 73,
Gary
WB6OGD

?

I use the same sweeper core code also on a nano using a somewhat different windows executable (TAPR-VNA)
No issues.
Extremely weird
--
HBTE Files section:?/g/HBTE/files
Erik, PD0EK

Test option:
When you start sa.exe and activate file/connect... , do you also see "Mockup"?
Click on mockup and OK
Then view/view log
Log window opens with "empty"
Then click "RUN" and see if the log window populates.
The mockup scanner does not log datapoints or replies but the rest should be there
--
HBTE Files section:?/g/HBTE/files
Erik, PD0EK

Erik,
We are getting somewhere!
I did not know you have to open the log window before doing a sweep.
When I do, I see the Nano IS sending back good data..
only problem is it stops at about 10 (doing sweep of 100).
This is why I see only a section on the left of the graph!!
Something is timing out?

Doing it in Mockup like you asked, I get this:
>>o483500483
>>v1
>>m
>>s100
>>e-1
>>t90
>>b533500533
>>a433500433
>>v1
>>w1000
>>o433500000
>>v0
>>o483500483
>>v1
>>p6 0
>>p5 -30
empty


Gary

Here is from the Nano:
<<x54
<<x49
<<x49
<<x57
<<x51
<<x54
<<x52
<<x53
<<x76
<<x52
<<x54
<<x51
<<x53
<<x54
<<x52
<<x61
<<x57
<<x81
<<x111
<<x96
<<x229
<<{
<<Steps: 100_
<<time pr step: 90_
<<Stop: 533500533_
<<Start: 433500433_
<<VFO: 1_
<<Output frequency: 433500000_
<<VFO: 0_
<<Output frequency: 483500483_
<<VFO: 1_
<<Parameter? 6 = 0_
<<paramenter=6_
<< -30_
<<Parameter? 5 =
<<Gattenuate=60_
>>e-1
<<callin atten with60_
>>w1000
<<paramenter=5_
>>p6 0
>>p5 -30
empty

Plot is just over to the left..? not enough points to plot!
Gary

Gary,
did you reduce BUFFERSIZE to 32 in the Nano C-code as I mentioned in message #721?
With this change communication with the SA.EXE and the Nano worked fine for me. I can run 3000 points without any problems.?
--
Joerg, ex-DB2OO

Joerg,
NO, I missed that..? well I remembered something about reducing it, I know I tried 64 without any change..
BUT.. 32 WORKS!!!!
You are good!? THANK YOU VERY MUCH!

I will have to try to understand this..?? There is enough dynamic memory for 512.. so says the compiler..
Bigger buffer spits out data too quickly?
73,
Gary
WB6OGD

The problem is in the USB serial driver. If you give a large buffer to send it crashes. With the Arduino monitor you get very small transfer.
--
HBTE Files section:?/g/HBTE/files
Erik, PD0EK

开云体育

YES.
How do you get away with it with your 32bit Zero?? It does it all in hardware and is fast enough?
73,
Gary
WB6OGD

Hi Group.

I also had not realised the Logger window had to be open.

With the logger window open I can reduce the speed down to 0 and it works for a single scan.? With the logger window closed it hangs.? If I choose run with the logger window open then it manages a few sweeps then hangs.

The data is sent from the Arduino at the same speed regardless of whether or not the logger window is open, so it must be a problem at the PC end.? The arduino is sending the data very much faster than the display update in the Tiny-SA application.? A 300 point sweep takes < 1 second to send the data.? The tiny-sa.exe takes around 12 seconds to plot it.
Moving the mouse over the sweep slows it to almost stopped, but still the data in the buffer is being handled and the sweep continues.

This is the data from the logger window at a hang:

<<x37
<<x39
<<x42
<<x42
<<x42
<<x46
<<x37
<<x44
<<x43
<<x41
<<x41
<<x42
<<x41
<<x45
<<x41
<<x41
<<x46
<<x41
<<x42
<<x43
<<x46
<<x42
<<x55
<<x112
<<{
<<Steps: 300_
<<a VFO: -1_
<<x29300
<<E
<<time pr step: 0_
<<Stop: 533920533_
<<Start: 433920433_
<<VFO: 1_
<<Width: 10000_
<<Output frequency: 433920000_
<<VFO: 0_
<<Output frequency: 483920483_
<<VFO: 1_
<<Parameter? 6 = 0_
<<Parameter? 5 = 0_
<<}
<<x43
>>m
>>s300
>>e-1
>>t0
>>b533920533
>>a433920433
>>v1
>>w333
>>o433920000
>>v0
>>o483920483
>>v1
>>p6 0
>>p5 0
<<x46


I tried a 1000 step single scan with speed zero and Logger Window open that worked (very very slow to plot - the data comes from the ESP32 in around 2 secs).? The logger window slows things considerably, which is strange as that should not be a very time consuming task on a modern PC.
My thought is that the serial comms is OK as lots of data seems to be buffered OK, but there is a problem in the tiny-sa.exe.? Is there a lot of maths going in in the application or is it just converting the data values to db and plotting?
73
Dave M0WID

There's a lot left unsaid in the Arduino documentation.
For example, from? ?
"Serial.readString()?reads characters from the serial buffer into a String. The function terminates if it times out"


So how big is the buffer?
Exactly what happens when it gets full?

Seems best on Arduino to only ask the Serial library to do low level character IO one byte at a time.
Do everything else in code you have some control over.?

Jerry, KE7ER

With some poking around on the web, it appears that the serial read buffer is 64 bytes.
So Serial.readStringUntil() might be suitable for grabbing a newline terminated tinySA command from the host.

The timeout on that is always in effect, though Serial.setTimout() takes a long (32 bits) to specify how many milliseconds.
and 2**32/1000/60/60/24 is almost 50 days.? Though they don't bother to actually say how long the timeout can be.
I can easily imagine they arbitrarily break the timeout after a few seconds.
They do limit delayMicroseconds() to 16383 microseconds max, I have no idea why.

This lack of concise documentation is disturbing, I'd never know for sure if I had handled all the edge cases.

Jerry, KE7ER

Dave
You just missed post #828,
Joerg has the solution.
In the tinySA.ino file change the line:
?BUFFERSIZE 512
to
?BUFFERSIZE 32

You have the same problem I had.? The fix WORKS.
73,
Gary
WB6OGD

I'm not sure what the output buffer does for us other than waste RAM.
Why not send each binary byte on its way individually with Serial.write()? ?

Serial.write() is blocking.
If there is no room for your byte in the transmit serial buffer,
the program will hang up in the Serial.write() function until there is room.

Function Serial.availableForWrite() will tell you how much room remains in the transmit buffer.
If you ask when the system is quiet I believe the answer is 64.

Where we need the buffer is on input, waiting for any command to be terminated with a \n
before parsing.

Jerry, KE7ER

The reason is speed if you are using CDC over USB
USB CDC transfers have substantial overhead so the more bytes you send in one send the faster?


--
HBTE Files section:?/g/HBTE/files
Erik, PD0EK

Arduino's vary, I have no idea what they all do with regard to the UART link..
But let's assume the Nano, which is probably the least capable of what folks here are using.

The Nano's ATMega382P chip sends Serial data out over a 115kbaud UART link to the USB chip.
That UART link is almost certainly the bottleneck, as the slowest that USB 1.0 operates is 1.5mbits/sec.
If the USB chip is ridiculously slow on single bytes, the queue maintained in the RAM by the Serial library
(I assume 64 bytes) will back up and you will get some nice long bursts anyway.

Each RSSI sample is 3 bytes, an 'x' followed by two binary bytes of data.
Over the UART link, that's 30 bits, including start bit and (I assume) one stop bit.
At 115kbaud, each sample takes 30/115000.0 = 0.00026 seconds to transfer, or 0.26 milliseconds.
So if the delaytime between samples is kept at 0.3 milliseconds or more, the UART should be able to keep up.
I believe the "T" command operates in units of 100us, so that's a minimum of 3 as an arg to the "T" command.

My point is, if the Serial library is giving us a 64 byte send buffer in RAM already,
there is no point in having any RAM buffers in tinySA.iso when targeting the Nano.
If your Arduino has a 115kbaud link involved in sending out Serial data, that is the bottleneck, not USB.
A UART has no protocol beyond the bit level,? sending out data as packets is not any more efficient.
And if USB is the bottleneck, it would have to be an awfully stupid USB implementation of
the slowest possible USB standard to not?keep up with a delaytime of "T 1", or 100 microseconds.

If you did want faster data transfers, then remove the 'x', so two bytes per RSSI sample.
If the '{' at the start of the transfer is not sufficient to keep everything in sync,
than we'd best fix whatever is trashing data transfers.

Jerry, KE7ER

Some Arduino boards have a processor chip that integrates a USB interface.
Sending data with the Serial command would not involve any UART at all,?
could be relatively fast.

The UART on the Nano can go considerably faster than 115kbaud:
? ??
However, the CH340G UART-to-USB chip used on the Nano clones does max out at 115kbaud.
? ??
We could go around the CH340G chip by hooking up an external UART-to-USB dongle like this
? ??
to the ATMega382P's RX and TX pins.? Then we're good up to 1000kbaud if it can successfully
negotiate the baud rate between the ATMega328P and the CP2102.

Regardless how it's done, I doubt there is any need for more than the 64byte buffer
implemented by the Arduino Serial library.

Jerry, KE7ER

A few corrections:

> The UART on the Nano can go considerably faster than 115kbaud:
>? ? ?

The CH340G datasheet states:
" CH340 supports common baud rate: 50,75,100,110,134.5,150,300,600,900,1200,1800,2400,3600,4800,9600,14400,19200,28800, 33600,38400, 56000,57600,76800,115200,128000,153600,230400,460800,921600,1500000,2000000 and so on."
The 115.2 kbaud limitation in the CH340 datasheet I saw previously was apparently only with regard to IrDA links.
So no need to go to the CP2102.

> Then we're good up to 1000kbaud if it can successfully negotiate the baud rate between the ATMega328P and the CP2102.

Been awhile since I've messed Nano's.
But now that I think of it, I guess both ends do get explicitly configured to a specific baud rate.
No negotiation required.

Most of the digital stuff I do is 3.3v these days, using the Nano's 5v IO pins to drive 3.3v devices is problematic.
The ATMega382P chip on the Nano will run at 3.3v, but is only guaranteed to work with a clock of up to 13mhz or so.
However, many have found it to work fine on 3.3v using the standard 16mhz clock used on the 5.0v Nano.
But you can configure it to divide that clock by two, bringing the processor clock down to 8mhz.
? ??
? ??
Might be worth looking into, as the Nano is very very cheap.

As you can see from the second link, there are some hardware changes required as well.
The CH340 datasheet says it will work fine at 3.3v as well.

Jerry, KE7ER

The bit-banged SPI interface could also be a factor in the max achievable sample rate
if the UART baud rate were increased up from 115.2kbaud.
Using hardware SPI pins, the Si4432 could be run at up to 10mhz clock speeds.

Looking at the tinySA.ino code, time spent on the SPI interface reading the RSSI
is not?accounted for when waiting between samples for the delaytime value specified
by the "T" command.? That may explain the mysterious "*2/3" factor here:
?
Jerry, KE7ER