Chorus RF Laptimer – 4in1 Part III – Wifi Setup

This steps requires some patient, wlan always makes some troubles. Took me nearly half an hour, since than it worked more or less stable, sometimes i have to double connect. Please test it also without a android if you have troubles. Androids hates it if wlan have no internet connection, sometimes it doesn’t really add routes for the local network -> Means it show connected but your mobile phone sends nothing to the access point. Because android want to keep the user into dark(or i would say stupid^^) you don’t have many debug options per default. Better try with Laptop if you had too much troubles, lets get started with the wiring setup:

Wire the DT06 modul like here and power your laptimer, it took ~0.4A at 12V if it takes much more current please double check the soldering and connections.
1) Install Chorus RF Laptimer App
2) Find Wifi “Doit_WiFi_…..” and connect to it, it should appear immediately after powering on. (<5secounds)

 

3) Confirm you would like stay connected, even if your laptimer has no internet

 

 

 

 

4) Open your browser and connect to “192.168.1.4”. If you are connected go to the serial settings under module.
5) Change baudrate to 115200
6) Got the network settigns and change Socket Type to UDP Server

 

 

 

 

 

 

 

 

 

 

7) Confirm new settings with restart

 

8) Wait till the restart finished

 

 

 

 

 

 

9) Start the laptimer app and click on “connect via wifi”. Be sure that your are still connected to the “Doit_Wifi..”. If it work you should see connected to 192.168.4.1 (It connects always to the gateway, if you see something different something is wrong, verify you are not connected to your home wifi network)
10) If it worked you should see immediately the lipo voltage. If you still see 0V there is something wrong (except you have an hardware error with the adc)
11) The fun begins setup your pilot and the race can start…

 

 

 

 

 

 

 

 

 

 

New RXSR firmware (fport version) with bugfix

Took a look at frsky homepage and found new firmware version for the rxsr fport edition come out this year: 2019-01-09

Just download it copy it to the sdcard on the Taranis under Firmware, wire it like on this picture, go into the Menü -> 2/9 SDCARD/Firmware and choose right version -> select flash external device, wait for loading screen -> done

If you have a normal X9D Taranis take a look oscarlians blog. Be aware the power supply/red pin is not in middle, so you have to adjust the wiring.

Omnibus F4 V3 pro -> uart6 tramp issues

After trying to forget the usb troubles i started with testing the final setup. Go into the OSD Menü (left stick: left, right stick up) and tried to change the Tramp transmitting frequency under features -> TR.  Normally should be there depending on t he settings Band “Fatshark” instead there was “Boscam A”. It was kind strange but lets try it, after confirming new channel with set nothing happens! Normally you should get white noise in your FPV goggles because the channel should change.

Confirmed soldering to the right uart pin, must be the TX pin, because its a half duplex protocol. Also the right serial was set in betaflight to IRC Tramp -> Serial6. Also the cli option vtx_halfduplex was set to “ON” like its default.

Okay lets go deeper and measure the signal:

Looks like betaflight trys every second a communication to the tramp
Something is blocking the Bus, the 3V3 voltage step shows clearly there is something wrong

Lets try uart1 as reference, worked with first try:

Capture signal on uart1 tx

Lets take a look to betaflight wiki: On OMNIBUS F4 V3 and later, serial RX is UART6, not UART1.

So conclusion is that Uart6 TX Pin is not mapped directly to the uart6 tx pin, i assume there must be some hardware inverter used to receive sbus signals which is blocking the signal.

Its still pita, without schematic we have to believe what we get and debugging is hell, hopefully we will get a open schematic flight controller with a F4 like the old CC3D. As workaround i use now Uart1 TX Pin, luckily i have one uart left.

Omnibus F4 usb issue

After changing flight controller because of USB i wanted to start the setup, so i connected copter via USB –> “NO SERIAL APPEARED”

I got really salty because that’s was the only reason why i changed the omnibus. But question was still why, took a look into the linux kernel log. (enter dmesg in console):

[316073.353128] usb 8-2.4.3: device not accepting address 56, error -71
[316073.537119] usb 8-2.4.3: new full-speed USB device number 57 using uhci_hcd
[316073.957079] usb 8-2.4.3: device not accepting address 57, error -71
[316073.958253] usb 8-2.4-port3: unable to enumerate USB device

Found only waste to error Code -71. Nothing useful at all in the whole internet )=. If you have something for me please post it! Only after connecting several times serial appeared very rare, tried a standalone onmibus without anything else connected which was lying around:

[316781.674161] usb 8-2.4.3: new full-speed USB device number 58 using uhci_hcd
[316781.933188] usb 8-2.4.3: New USB device found, idVendor=0483, idProduct=5740
[316781.933191] usb 8-2.4.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[316781.933193] usb 8-2.4.3: Product: OmnibusF4
[316781.933195] usb 8-2.4.3: Manufacturer: Betaflight
[316781.933197] usb 8-2.4.3: SerialNumber: 0x8000000
[316781.937288] cdc_acm 8-2.4.3:1.0: ttyACM1: USB ACM device

worked at first try, so i assumed they forget the pull up resistor on D+ for detecting the USB Device, what for example happened on the blue pill (stm32 based arduino board)

Because it worked one time i assumed its an electric issue, i measured everything, found 22 Ohm in Series at D+ and D-, strange thing was everything was the same with the working one. Strange i did not found the 1k5 pull up resistor, found out its internal on the stm32F4 (bluepill uses F3) => why the hell it does not work than? Had no idea left, so i put a lot of solderflux at the usb connector and heated with solder iron to the usb connector and the serial resistors. Connected again -> suddenly it worked out of the box. However betaflight was really slow, saw always loading screen, on laptop it work fast as it should -> found out 3d printer was using maybe nearly complete USB bandwidth.

Lessons learned: Test flight controller and usb right before you built it in and don’t use other serials while one is occupied by the 3d printer.

Obsession repaired (=

Copter Season is starting already (: so i had to repair and maintenance my old copters, unlucky i broke the usb port from my Obsession Quad, I replaced the Omnibus F4 V3 flight controller with the pro version(means no current sensor on board anymore, however i am able to get the current sensor data from the 4in1 ESC modul). See the detailed spec of the Obsession under Quadcopers.

Obsession before with broken usb port
Before Repair, under the hood
Connecting 4in1 ESC with the new Omnibus F4 pro

 

Chorus RF Laptimer – 4in1 Part II – Flashing software

Next step is to get the software on the arduino. Get the latest source:

git clone https://github.com/voroshkov/Chorus-RF-Laptimer.git

So i started my Arduino IDE (i used version 1.8.5), open the Ino file in the Chorus-RF-Laptimer folder and click on compile and following error appeared ):

/tmp/arduino_build_387930/sketch/mainDetectionAlgorithm.h: In function ‘void runExperimentalLapDetectionAlgorithm()’:
/tmp/arduino_build_387930/sketch/mainDetectionAlgorithm.h:53:41: error: ‘getDeepFilteredRSSI’ was not declared in this scope
rssi2 = getDeepFilteredRSSI();

Took a short look into the source, but didn’t find the getDeepFilteredRSSI, maybe it was forgotten to check in. So i rolled backed to latest stable version:

cd Chorus-RF-Laptime
git checkout -b 0.7.9

And finally it build through (: with git tag you can see all other tagged versions that exists

For programming Arduino’s i purchased a USBASP programmer. They are quite cheap and available for some dollars from china (e.g. banggood)

USBASP programmer connected to the Arduino


You have to connect folling PINs:

MISO<->MISO
SCK<->SCK
MOSI<->MOSI
RST<->RST
VCC<->5V
GND<->GND


Connect programmer to your PC, select right Arduino in the IDE -> “Arduino Pro or ProMini with Processor ATmega328P (5V, 16Mhz)” and also the right Programmer “USBasp”. Finally program it via Sketch -> Upload using Programmer.



Flashing with the Arduion IDE


Now repeat this for the other three and done (=

Chorus RF Laptimer – 4in1 Part I – Soldering

Got some time ago a 4in1 Laptimer pcb from bernd, see http://kwads.at/chorus-rf-laptimer-4in1   (schematic & layout is available under https://github.com/ps915/Chorus-RF-Laptimer-PCB)

Started ordering parts immediately, meanwhile all parts are arrived and I’m finally able to start soldering it together. Here is my order list (from banggood+aliexpress, be aware it could take 2-3 weeks to get all stuff):

Soldering is quite easy, even if you are not that experienced because of the big 1206 SMD Resistors. (Blue are 100, Orange are 1K, Green 10K, yellow are the shottkys, if this is your first pcb (you could daisy chain the 4in1 latpimer to get a 8in2 laptimer) you have to create a solder bridge or solder headers to jumper it later. For the uart loopback (black left one) and for the voltage sensor (top black one).
To be on safe side please power the DC/DC Converter and verify if you get really 5V on the output side. In my case the first DC/DC converter started immediately burning without anything connected.(See burned surface on the IC on the left) Luckily the pieces are cheap and i had spares from the pack of 5.
Soldering the 5.8 Ghz receiver moduls


Testing DroneBridge

Found a very cool article on hackaday about using wifi to transmit video data, however without the 802.11 protocol, instead using a own digital data link, so streaming data like on analog system, however still digital only without protocol overhead acknowledges and frames and so on.

The cool thing is this stuff is open source and there exists ready to use images for the raspberry (preferred version 3)

More detailed infos under:
http://wolfgangchristl.de/dronebridge/
https://github.com/seeul8er/DroneBridge

For the first setup you need:
2x raspberry, one with camera
2x usb wlan module with packet injection support

The problem is when you buy consumer wlan sticks you can not see what you get, even if buy the same product / wifi dongle like the TP-Link TL-WN722N the next one could have a different chipset already inside. The problem is that the chipset is very important, because it depends on it if the device supports monitor/ packet injection mode or not. At the moment only the Ralink RT3070 and Atheros AR9271 are quite good supported.

To be sure you get such chipset i would recommend you usb dongles from alfa, they are used by wardrivers and you can be sure that you get always the same chipset. With the TL-WN722N from the tp-link you would get most likely the AR9271, but you can never be sure.


AWUS036NHA with the AR9271 chipset
ALFA AWUS036NH with the Ralink RT3070 Chipset 

Be aware there exist also a old version of it (AWUS036H), without 802.11n support. It supports also monitor mode, but has a Realtek RTL8187 Chipset

To get it runnig, connect the alfa via usb the raspberry, flash the dronebridge image and powert it. The rasperry with camera gets automatically in transmittingmode and the pi without cam in receive mode. Connect a display to the hdmi port (to the pi without cam) and you should already see the camera stream.

If you don’t get a anything maybe you have to disassemble the antenna on the receiver side, because of our test setup where transmitter and receive where very close together <1-5m we had most likely the overdrive effect.

DroneBridge on raspberry without Camera waiting for incomming data
Picture of our first little chaotic testsetup
First received stream after disconnecting rx antenna (necessary in near range cause of overdrive)

So the next step will be a real test of the range in the wild field, hopefully winter is over soon…