# SMD viewer MkII

My hobby desk is limited in space nevertheless I added a SMD viewer with a relatively long working distance.

Here the result. In the screen you can see some 0603 components.

I started reading this very nice post http://operationalsmoke.blogspot.it/2014/05/diy-usb-soldering-microscope.html

I found in my cellar an old camera made in URSS (1965?). I made some test of the focusing distance of the lens. I used an empty can of tuna in oil as spacer ( use protective gloves when cutting the tin). I took the lens threaded mounting ring from the old camera and fixed it to a hole in the can.  The can is painted mat black to avoid light reflections.

A black plastic box houses the webcam.

I bought a cheap HD (720p) webcam with manual focus (www.banggood.com).

To modify the webcam remove the webcam board from its housing. Unscrew the lens mounting and cut the black plasic ring. DO NOT TOUCH the red infrared IR filter placed at bottom near the camera sensor. All optics exited the front after cutting the upper black ring. Do not touch the filter glass.  Protect the sensor with paper tape when attaching the camera to the new box. Fix the camera pcb using nylon spacers and screws.

Before attaching the camera card, experiment a little bit with the distance of the lens as the magnification depends on the lens type and the layout of the camera.

I use the camera with a Windows PC 10. The applications I prefer are VirtualDub and Windows native Camera. VirtualDub seems a bit faster.

The positioning of the camera must be very solid to ensure stable images. In my setup I placed 9 neodymium magnets on the back of the plastic box and an iron plate (from an old CD drive cover) is screwed onto the top of my holder. The magnets allow to  move and unplug the camera easily.

To obtain a wide depth of field a low aperture and a strong lighting must be used.

I made a try of a home made lamp with a 10 watt led and a focusing lens taken from an old video camera. A fan cools the led aluminum radiator. Some magnets are used to suspend the lamp.

 Costs Lens (taken from old photocamera) -- webcam 13 € plastic box 3 € neodymium magnets 2 € spacers, screws, paint etc 5 € Led 10Watt + power supply + fan 7 € Lens for led (taken from an old videocamera) -- Total 30 €

email: ik1xpv AT gmail DOT com

# R820T2 update - BBRF103_2 PCB

A bug crashed the USB3.0 stream at random time while the R820T2 tuner was active. ( Troubleshooting BBR103 )

It was caused by a spurious coupling via the 3V3 power supply.

I thought of a problem in the firmware of FX3 while the cause was hardware.
I decoupled the R820T2 3V3 power supply using a separate LDO from the 5V USB bus to
solve the problem in the prototype.

The R820T can be used to receive frequency band in the range 30MHz -1800MHz.
The tuner uses a clock generated by Si5351A at 32.000MHz, the REGDIV bit of reg 4 is set to 1 to divide it by two internally to the nominal 16MHz.
The IF output is selected at 5MHz ( I used up to 7.5MHz) and it’s sampled by the ADC at 64Msps and then decimated down to 8Msps or less. The R820T data sheet states that the standard IF filters are implemented for 6/7/8 MHz channel bandwidths.

The LNA, the mixer and the VGA gains can be set manually although their precise values are absent from the datasheet.
They can also be set automatically via automatic gain control (AGC) in order to optimize the signal to noise ratio (SNR).

A revision of PCB  BBRF103_2 has been designed: ( www.steila.com/test/BBRF103_2B.pdf )

- A separate LDO voltage regulator for R820T2 has been added

- 1000 uF capacitors with a mosfet delayed switch has been added to 5VBUS and 3V3 R820T2.

- Antenna power supply with software switch added to HF and VHF input

- SMD pad dimensions have been increased a little bit to simplify manual assembly.

- Board profile modified to house SMA connectors.

- BAV99 smd layout corrected.

- Possibility of external frequency reference input to Si5351a  ( P8 ).

- Aux clock ouput  (P9).

I just received the manufactured pcb and possibly I will test it in the next month.

# BBRF103 and ExtIO.dll ver. 0.96 get 32 MHz span

End of September 2017 I was googling “SDR and FX3” when I found a nice SDR project named Booya SDR (http://booyasdr.sourceforge.net/BooyaSDRDoc.pdf , http://booyasdr.sourceforge.net/).

It uses the same USB3 Cypress Explorer Kit Board while the ADC is a LTC2206.
Reginald Eisenblatt, gave a presentation on the BooyaSDR ( January 23, 2017, at Linaspace see http://www.amrad.org/ ).
Some video at https://www.youtube.com/watch?v=uF6y0ETTJFA , notice the Waterfall with multiple rows!

The BooyaSDR application is very clever. It uses gcc compiler with pthreads and fftw library. The FX3 firmware is loaded at run time using the Cypress download protocol.

I decided to use the same software environment and compiler to test a version of ExtIO_sddc.dll for BBRF103 with pthreads lib.

To install CodeBlocks 12.11 IDE , https://sourceforge.net/projects/codeblocks/files/Binaries/12.11/Windows/  download codeblocks-12.11mingw-setup.exe  -> Default installer WITH compiler (MinGW).

ExtIO_sddc.dll ver 0.96 project links to the following libraries:
copy Pre-built.2 directory contens into /lib/pthreads/.
Fftw:http://www.fftw.org/
ftp://ftp.fftw.org/pub/fftw/fftw-3.3.5-dll32.zip

CyAPI_gcc:
a gcc compiled version of CyAPI.cpp.

The directories structure I used is:

ExtIO_sddc \BBRF103_SE         FX3 firmware,
ExtIO_sddc \source\                 sources, ExtIO_sddc.cbp,
ExtIO_sddc \Lib\fftw                 fftw library,
ExtIO_sddc \Lib\CyAPI_gcc       CyAPI gcc library ,
ExtIO_sddc \bin\debug             debug ExtIO_sddc.dll, HDSDR ,
ExtIO_sddc \bin\release            release ExtIO_sddc.dll, HDSDR.

The bin\release and \bin\debug  directories contain:

HDSDR.exe
ExtIO_sddc.dll                         release or debug
BBRF103_SE.img                     BBRF103 firmware image
libfftw3f-3.dll

Sources repository :

https://github.com/ik1xpv/ExtIO_sddc-Ver0.96

An archive file of project with compiled binaries can be download at

http://www.steila.com/test/ExtIO_sddc_v096.zip

MD5    6efcd88bdc14107389cae5d6f7efe3dc

SHA-1 88ef3f3ba6276da694f6e92ebb71d987046de100

Hardware:

The BBR103 has been updated to version 0.2 with the following patch.
- RAND patch: a wire has been added to control the RAND pin of ADC using GPIO20 of FX3.
This option allows the control and test of RAND feature of ADC (see pg 14, 24 of http://cds.linear.com/docs/en/datasheet/2217f.pdf).
The wire connects RAND (U3-pin 63, R7,R9) to GPIO20 ( BGA K7 = PIN25 J6 FX3 SS kit).

Firmware:

The Firmware source can be found into the archive file of project under \Firmware directory

Status:

The 0.96 version is still a preliminary release with some bugs. It operates in HF mode only.

Problems remain in use of R820T2 tuner, and a  post on this argument will follow.

The digital signal processing frontend uses a the Halfcomplex-format DFT (http://www.fftw.org/fftw3_doc/The-Halfcomplex_002dformat-DFT.html).

The FFT output is sent to HDSDR with a selectable rate of 32 Msps or a decimated one at 16, 8, 4, 2 Msps.

Filtering and tuning is made using overlap and add with frame of 1024 as 768 +256 samples. The filter time responses are 257 sample long.

When 32Msps is used the local oscillator of HDSDR is fixed to 16 MHz at centre of spectrum and the fine tuning of HDSDR allows reception from 500 kHz to 31500 kHz, while with lower sample rates the local oscillator can be tuned with 125 kHz step while the fine tuning is made by HDSDR.

At this development stage ExtIO_sddc.dll has a GUI dialog with 4 tabs :

• Status - reports ADC rate and I&Q rate.
• BBRF103 -  buttons :

LW-MW this is used to modify the FFT output filtering to receive the low frequency band.
HF - standard HF setup .
VHF - enables R820T2 ( it is disabled, to enable undefine _NO_TUNER_ in config.h and recompile)
DITH - enables the ADC dither.
RAND - enables the ADC randomize.

TRACE - enabled in debug mode  to trace some signals to log files.

• Test

RF virtual tone: it requires BB103, virtual tone,
RF virtual sweep: it requires BB103, virtual sweep,
IF virtual tone: NO hardware required, virtual tone ,
IF virtual sweep: NO hardware required, virtual sweep,

Hereafter a video recorded with  a random wire antenna 5mt long on the balcony (in the city).

# Troubleshooting BBR103

"Troubleshooting or dépanneuring is a form of problem solving, often applied to repair failed products or processes on a machine or a system. It is a logical, systematic search for the source of a problem in order to solve it, and make the product or process operational again. Troubleshooting is needed to identify the symptoms. Determining the most likely cause is a process of elimination—eliminating potential causes of a problem. Finally, troubleshooting requires confirmation that the solution restores the product or process to its working state."   (from:https://en.wikipedia.org/wiki/Wikipedia:Troubleshooting).

BBR103 prototype is alive, nevertheless some bugs limit the performance. Hereafter the syntoms and some investigation to hopefully solve them.

I focused on the HF operation using HDSDR with IF bandwidth of 16 MHz as shown in the following picture.

The BBR103 in the picture is connected to a 5 meter wire on my balcony in the city.  The ADC performance seems good as espected.

Nevertheless I notice the following problems during its use:

001)  (SOLVED)  The signals had a periodic distortion (-50 dB down)   at 10ms time distance. I noticed it using a 10MHz reference generator.

The bug was periodic with the period of the FRAMEN lenght buffer. Digging in the rfddc code I got the bug. It was mirroring the wrong past frame.

002)   There are some distortion on the signal that are at random time like the following I got in a IQ waveform recorded with HDSDR.

The distortion looks like a 90° phase shift. I imagine that the cause is in the dll. The randomness of the  behaviour keeps the search difficult.

003) The USB communication fails at random time (up to some tens minutes). I got the following debug message:

...
Xfer request rejected. NTSTATUS = c000000e
AbortXferLoop()
...

The USB device disconnects.  It requires reset to start again.

My knowledge about USB is very low and I have to learn everything. I found some hits:

I used the following procedure:

1) Load the SDRx3B.img in BBRF103.

2) Run HDSDR and then close it ( to initialize the BBRF103 hardware).

3) Run the FX3USBread console application from FX3GPIFnoise.zip.

I use a script file. In this example it has a 3 minutes run.

d:\DEV\FX3GPIFnoise>time /T03:15 PM
d:\DEV\FX3GPIFnoise>FX3USBreadFX3USBread version 1.0
Press ESC for stopCount:22982361088 Speed:120.571MB/s Max:122.792MB/sDeviceIoControl failed (GetOverlappedResult error code=995)Operazione di I/O terminata a causa dell'uscita dal thread oppure della richiesta di un'applicazione.
d:\DEV\FX3GPIFnoise>time /T03:19 PM
d:\DEV\FX3GPIFnoise>PAUSEPremere un tasto per continuare . . .

It crashes at random time as it happens with HDSDR+ ExtIO_sddc.

I made the same test using Cypress stream application.

Power on of BBR103 with HDSDR + ExtIO_sddc.dll to program ADC clocks.

Run stream.exe  I got the same problem after some time ( 5 minutes in the example )

The bug seems to be in the FX3 device firmware because it happens with 3 different application.

..continue..

# Some variations of ExtIO_sddc.dll architecture

The ExtIO_sddc.dll processes the ADC real signal stream. The sampling rate is 64 MHz.
The output is a decimated I&Q complex signal stream at 16 MHz, 8MHz, 4MHz or 2MHz.
Filtering and tuning are integrated.

The dll uses CyAPI library to connect BBRF103 hardware via USB3.0.
One buffer’s time duration is about 1 ms at 64 MHz.
I configured USBthreadProc to run at high priority to be responsive to hardware timing.
The USBthreadProc output buffer is processed by the class RFddc that has an own buffer array of 16 elements.
The time of a circular turn of 16 buffers queue allows the digital down conversion algorithm of each chunk to complete on a separate thread.
The previously computed output vector is returned while the signal processing of the buffer is started. A priority for these threads below normal seems good enough.
Frequency domain signal processing is used. An overlap and add FFT scheme processes the buffer 65536 sample frame and overlap and save scheme glues the buffers together.

The following diagram represents the processing of one buffer frame and it is implemented in every thread of the RFddc pool of 16.

notes:

1) It is the input sample array of short. It is a real signal. The frame buffer is a sequence of 65536 samples (it can be seen as a sequence of 64 *1024 slice).

2) The last 1024 slice in the past is copied at the beginning of the array to form a frame of 65 *1024 = 66560 samples. This is the overlap and save scheme.

3) A complex array 66560 samples long is obtained from (2) adding a zero imaginary component.

4) Starting from 0 the array is divided into slices of 768 samples to implement override and add (Overlap and add method)  with an overlap of 256 and a fast Fourier transform (FFT) of 1024 sample frame.

5) Every 768 slice is copied into a 1024 one adding a tail of 256 sample zero filled.
85 slice of 1024 complex samples.

6) A FFT forward is applied to the every 1024 slice. 85 slices in frequency domain are computed.

7) For every slide a circular shift of the FFT’s bins is used to implement tuning to the IQ carrier frequency.
The resolution is 64000000/1024 = 62500 Hz. This coarse step is good enough for HDSDR tuning that uses its own fine adjustment. A phase adjustment is required depending on the tuning bin position.

8) A low pass filter of the signal is implemented as fast convolution (https://en.wikipedia.org/wiki/Convolution#Fast_convolution_algorithms) multiplying the FFT bins by the complex conjugate (https://en.wikipedia.org/wiki/Complex_conjugate) frequency response of the filter (Hw*). To use the fast convolution approach the length of the time filter response ht is limited to (1024 -768) +1 = 257 samples.

9) Decimation in frequency is used. The implemented output lengths are 256,128,64,32 that obtains output rate of 16MHz, 8MHz, 4MHz, 2MHz. It is made just copying the decimated FFT bins chunk near zero frequency.

10) The resulting output is a sequence of decimated FFT ( 256,…) bins. Steps (7) (8) (9) are implemented together in a copy and modify loop.

11) The 85 slices of decimated FFT.

12) The FFT inverse is computed.

13) The time output is computed with overlap and add of the 85 slices. The first 256 samples and the latest 512 are dropped using overlap and save (Overlap save method)  of the 64 * decimated FFTN samples frames.
The function has an array of 65536 samples input and returns an array of 16.384 samples at 16MHz, 8.192 at 8MHz, 4.096 at 4MHz, 2.048 at 2MHz.
A separate thread processes the signal from each one buffer.

CPU use of HDSDR and ExtIO_sddc, V0.95 ADC 64MHz, IQ 16Msps ; 60 s plot

I made some debug measuring the time jitter of USBthreadProc 16 buffer cycle.
The theoretical time is 16 * 1.024 ms = 16.384 ms.
Here after a plot of the measured duration time - 16.384 ms.
The plot shows that the peak jitter is within +/- 3mS.

USBthreadProc 16 buffer circle timing jitter running at 64 MHz in 16MHz sampling output, 60 s plot.

I named this release version 0.95 and I save it in a separate GitHub repository at:

https://github.com/ik1xpv/ExtIO_sddc

I switched to the integrated Visual studio Git and it was simpler to me to keep it separate from other BBRF103 project components.

To be continued.

These are exciting times for homemade construction of Software Designed Radio (SDR).  Our laptop and desktop have more computing power. Better compilers simplify multi thread programming. Computer interfaces run at higher throughput rate.

I designed the breadboard BBRF103 to learn how to use and to test the following components :

• FX3 SuperSpeed Explorer Kit USB3.0 transfers the ADC sample stream to the PC.
• ADC (LTC2217) samples the real data at 16 bit up to 105 Msps.
• 0-30MHz input, attenuator (0,-10,-20 dB) and LPF transfer antenna signal to the ADC.
• Tuner ( R820T2 ) down converts signals in the 30-1800 MHz range to the ADC.
• Clock generator ( Si5351A ) outputs the clocks to the ADC and the R820T2.

In other words the idea is to avoid the Digital Down Converter (DDC)  Custom or FPGA chip in between ADC and PC. The full HF radio spectrum is processed by the host computer connected via an USB3.0 port.

BBRF103 is placed in series between Antenna and Computer. A modern pc (I5-I7 CPU or higher) equipped with USB 3.0 is required.

The R820T2 chip has been added to look at its performance with a 16 bit ADC and wide bandwidth.

## Hardware

The hardware uses two separate antenna connectors  0-30MHz  and  30MHz-1.8GHz

I made the schematic using cut and paste of the main components test circuits.

The HF input (0-30 MHz) is routed to a multiplexer circuit. Some resistors  implement a step attenuator with value 0, -10 , -20 dB. The attenuator's output goes to a low pass filter and then to the ADC input via a balancing transformer. The ADC parallel output bus is routed to the FX3 SuperSpeed Explorer Kit using the kit IO connectors. The Cypress kit uses some GPIOs as control of multiplexer and ADC while a I2C bus is used to program the Si5351a clock generator and the R820T2 tuner.

The input multiplexer other than the HF input selects the R820T2 tuner output.

The R820T2 uses an indipendent input (30MHz - 1.8GHz) connector.  The Si5351a tuner generates by the tuner reference clock; the first software prototype setup uses a 32 MHz. The software may program different reference frequency to move out of band spur signals.

The Si5351a generates also the ADC clock .  The pcb previews an optional backup alternative with a fixed frequency oscillator.

The Si5351a's reference Xtal is 27.000MHz. Another frequency may be used. This is the only frequency reference of all the hardware. The software will be able to compensate the accuracy of this xtal with a correction coefficient.

The clock is coupled to the ADC LTC2217 using a rf balancing transformer.

https://github.com/ik1xpv/BBRF103/blob/master/HARDWARE/BBRF103_scheme.pdf

An extruded aluminum box of 100 * 76 * 35 mm is large enough to accommodate the FX3 SuperSpeed Explorer kit and board PCB.

The size of the PCB is about 100x70 mm. Two 40x2 headers connect the FX3 SuperSpeed Explorer kit.

The PCB board contains the main components on the underside. The ADC has a copper radiator on the top. It taps the aluminum box to dissipate part of the ADC heat.

The two RF input connectors are SMA.

On the upper side there are the power regulator, pin connectors and two jumper cables in coaxial cable for the R820T2 clock and the IF signal.

The final assembly of the prototype shows the FX3 kit at the top of the BBRF103 board.

The prototype has a 5 volt Auxiliary Power Connector that was used during the first tests.  It is not necessary because the required current is less than 800mA and can be supplied by the standard USB3.0 connection.

The hardware scheme and pcb layout at https://github.com/ik1xpv/BBRF103/tree/master/HARDWARE .

## Firmware

The FX3 firmware is a modification of Cypress streaming examples. Some Vendor commands have been added to control I2C bus and to control GPIO e PWM output.

SDK comes with the Cypress Eclipse development enviroment. It's a nice exercise to learn how to use FX3.

BBRF103 uses the Cypress USB driver that comes with FX3 Kit.

The firmware source repository is  https://github.com/ik1xpv/BBRF103/tree/master/FX3Firmware

## Software

The prototype has been tested with the HDSDR application that i like a lot (THANKS to Mario Taeubel and Alberto di Bene).

I designed an ExtIO_sddc.dll. The name stands for ExtIO software digital down convertion. The dll task is to tune and to downconvert the SDR real samples, generating a IQ complex downsampled stream that is processed by the HDSDR application.

The software source repository is  https://github.com/ik1xpv/BBRF103/tree/master/ExtIO_sddc .

Here a video of BBRF103 prototype with a 1 meter wire antenna receiving local FM band in Turin. The PC used is a I5-3350P CPU @3.10GHz desktop

I prepared a portable setup for summer holidays using a Laptop  i7-7500U CPU @2.70 GHZ  2.90 GHz