Thread Tools
May 10, 2017, 10:49 PM
Registered User
Quote:
Originally Posted by Deathstroke5467
Hello haven't been here for a while as I've switched focus for a while... did (I believe it was artemen) ever release the schematics for that board he was talking about, I remember he had talked about it having significant increases in receiver sensitivity and possible a few other features?
I think this is the board you are referring to:
http://www.itluxembourg.lu/site/apmp...dolphin-board/
Sign up now
to remove ads between posts
May 10, 2017, 10:51 PM
Registered User
Quote:
Originally Posted by neo__04
Make sure mission planner is trying to connect at the correct baud too
Can someon list the correct baud rates?
Blue tooth?
Mission planner?
APM telemetry serial baud setting?
May 10, 2017, 11:43 PM
Registered User
007trains's Avatar
Quote:
Originally Posted by Upnorth4
Can someon list the correct baud rates?
Blue tooth?
Mission planner?
APM telemetry serial baud setting?
APM serial baud setting = SERIAL1/UART0=19 (ie 19200)
Bluetooth = 57600
Mission Planner = 57600 (Assuming your connecting via ULRS not USB)

To keep it simple everything on the ground should connect at 57600 and everything in the air at 19200

@flipflap This page still says to setup bluetooth to 115200 but we've since changed to 57600: http://www.itluxembourg.lu/site/usin...etooth-module/
May 10, 2017, 11:48 PM
Registered User
Quote:
Originally Posted by Upnorth4
Can someon list the correct baud rates?
Blue tooth?
Mission planner?
APM telemetry serial baud setting?
Answer to my own question from the ULRS website:
Remember that Mission Planner must be connected at 57600 bauds, but APM must be configured for 19200 bauds (SERIAL1 = 19)
It works also with a Bluetooth module and Android ground station software 3DR Tower, as described here. Just be careful to configure the BT module for 57600 bauds. There’s no need to configure the baudrate in Tower.


Please confirm this is correct for the latest version....
May 11, 2017, 02:55 AM
Registered User
Hi, I was submerging myself into the possibility of transitioning from an Atmel based LRS to an STM32F1 based LRS. In my search of already existing systems, to not reinvent the wheel here, I found it was already done before. As much as hardware as have software been made before yet it looks like it didn't take off, I would have imagined it would be like how the naze32 replaced the kk2.
Would there be specific reasons why it didn't got picked up?
Are there people working on that, maybe we can work together?
Do you have tips/useful information that would help me advance?

Thanks
May 11, 2017, 03:11 AM
Registered User
Thread OP
Quote:
Originally Posted by Upnorth4
Answer to my own question from the ULRS website:
Remember that Mission Planner must be connected at 57600 bauds, but APM must be configured for 19200 bauds (SERIAL1 = 19)
It works also with a Bluetooth module and Android ground station software 3DR Tower, as described here. Just be careful to configure the BT module for 57600 bauds. There’s no need to configure the baudrate in Tower.


Please confirm this is correct for the latest version....
This is correct for the latest version.
May 11, 2017, 03:14 AM
Registered User
Thread OP
Quote:
Originally Posted by 007trains
@flipflap This page still says to setup bluetooth to 115200 but we've since changed to 57600: http://www.itluxembourg.lu/site/usin...etooth-module/
Thanks for the notice it's now corrected.
May 11, 2017, 03:18 AM
Registered User
Thread OP
Quote:
Originally Posted by jelle737
Hi, I was submerging myself into the possibility of transitioning from an Atmel based LRS to an STM32F1 based LRS. In my search of already existing systems, to not reinvent the wheel here, I found it was already done before. As much as hardware as have software been made before yet it looks like it didn't take off, I would have imagined it would be like how the naze32 replaced the kk2.
Would there be specific reasons why it didn't got picked up?
Are there people working on that, maybe we can work together?
Do you have tips/useful information that would help me advance?

Thanks
This is an option and I'm interested in looking into it. If you've already got some experience with these boards it would be helpful if you can provide some advices about the best way to start with them. Which development board to start with, which IDE and so on. And apart from the price I'm not completely aware of the advantages of these chips againt for example Teensy boards. So any suggestion is welcome.

I'd also be interested to know if atmel C++ code can easily be used on ST chips.

I can google all that myself but I don't want to loose time reinventing the wheel if you've already got experience in this.

Thanks !
May 11, 2017, 04:16 AM
Registered User
Quote:
Originally Posted by flipflap
This is an option and I'm interested in looking into it. If you've already got some experience with these boards it would be helpful if you can provide some advices about the best way to start with them. Which development board to start with, which IDE and so on. And apart from the price I'm not completely aware of the advantages of these chips againt for example Teensy boards. So any suggestion is welcome.

I'd also be interested to know if atmel C++ code can easily be used on ST chips.

I can google all that myself but I don't want to loose time reinventing the wheel if you've already got experience in this.

Thanks !
In fact I don't have experience with STM32F1's, but I think it makes for a good project to gain experience in both the hardware and the software side of such a project. ST chips are programmed in C, there seem to be an arduino port for stm32 called stm32duino.

I just found that there exist a board (UHFDTF-10ch-32) and software (openLRSng32), so a working prototype probably also exist yet there is no reference anywhere, both board and code date from 4 years ago, maybe something was wrong with them?

These days I would base myself on the code examples of a working project like cleanflight, no need for IDE and compilation is explained in their github. You probably can just hook up a RFM23BP with an old spare naze32 laying around, that was my plan once I have the RFM23BP chip's.
May 11, 2017, 05:50 AM
Registered User

Artemen board


Quote:
Originally Posted by artemen
Btw, the V2 is in the final stage of designing. It is a completely new unit, not utilizing any hoprf modules, insted I have bulit the trancevier side myself with 40db amplifier on the RFin side of the si4330. That said it will run miniulrs code juat fine.

from Mobile
Nope here's the one I was talking about finally found it, I'll pm him to see what the progress is on this as it looks like he never released it?
May 11, 2017, 06:46 AM
Registered User
Thread OP
Quote:
Originally Posted by jelle737
In fact I don't have experience with STM32F1's, but I think it makes for a good project to gain experience in both the hardware and the software side of such a project. ST chips are programmed in C, there seem to be an arduino port for stm32 called stm32duino.

I just found that there exist a board (UHFDTF-10ch-32) and software (openLRSng32), so a working prototype probably also exist yet there is no reference anywhere, both board and code date from 4 years ago, maybe something was wrong with them?

These days I would base myself on the code examples of a working project like cleanflight, no need for IDE and compilation is explained in their github. You probably can just hook up a RFM23BP with an old spare naze32 laying around, that was my plan once I have the RFM23BP chip's.
Thanks for the info, I'll look into stm32duino, as I'd like to more or less directly port the ULRS firmware to this type of 32bits chips, so it will use the same algorithm and GUI.

If possible I'll try to keep the same codebase, with some #if #else for the different chips it will support. That's the approach that was followed by Ardupilot and it seems a good way to progress without too having to maintain two separate source codes.
May 11, 2017, 07:47 AM
Registered User
Just to be sure, ultimateLRS isn't open source, right?
May 11, 2017, 08:06 AM
Registered User
mike_o's Avatar
Quote:
Originally Posted by flipflap
Hi Mike, it's funny to see people coming back after the winter

I think your BT was configured for 115200 bauds, but it should now be configured for 57600 bauds (this was changed a few month ago).

Apart from this everything should be fine.
After fiddling with the setting (19200 APM serial baud rate, BT 57600, and checking/switching Rx/Tx cables from APM to LRS Rx), the Rx lost bind to the Tx. I had to re-flash the Rx, re-bind it, and do the setting (PPM on port 5) via the Tx again.

Then I tried again with the same result and another tour de re-flash/bind/set. Surely this is not normal? What is happening?

thanks
May 11, 2017, 10:09 AM
Registered User
Thread OP
Quote:
Originally Posted by mike_o
After fiddling with the setting (19200 APM serial baud rate, BT 57600, and checking/switching Rx/Tx cables from APM to LRS Rx), the Rx lost bind to the Tx. I had to re-flash the Rx, re-bind it, and do the setting (PPM on port 5) via the Tx again.

Then I tried again with the same result and another tour de re-flash/bind/set. Surely this is not normal? What is happening?

thanks
Normally nothing should require to reflash the RX because the firmware itself has no way to modify the flash (program) memory. If this happens, and if we exclude a defective chip (always possible) or flash memory wearing (even the SSD drives have a limited lifetime), the cause should be looked on the hardware / power supply. In particular the eeprom memory is sensitive to undervoltage (or shut down) during a write operation, as documented by atmel. However the firmware stores 7 copies of the data in eeprom so it's completely safe for the eeprom. I think here it's something about the flash (program) memory.

1) First check APM+ULRS without BT to test every part separately.

2) Then check the BT separately (connect it directly to APM at the right baudrate). Don't forget to chage the baudrate again after this test.

3) Then check your power supply, if you're using 1W modules they should be powered directly from the battery. If powered from battery, check the battery voltage.

4) Then check your antennas, don't use the stock antennas or monopole antennas. Very bad SWR could potentially have a unexpected effects. I'm not sure it could affect the flash or eeprom memory but after all it's stored as electrical charges.

5) Remember that orangeRX/wolfbox modules operate with the atmega slightly under the supported voltage for operation at 16MHz. In practice it works fine, and the firmware has a very strong redundancy for data stored on the eeprom, but this should be looked at as a possible cause too. Modules such as ULRS Mini have a much better design and run in the safe zone.

6) Check the boards voltage as seen by the APM in its log, just to be sure there's no voltage drops during operation.
May 11, 2017, 10:11 AM
Registered User
Thread OP
Quote:
Originally Posted by jelle737
Just to be sure, ultimateLRS isn't open source, right?
The version 1.06 is released under GPL so it's open source, however it has limited features in comparison to ULRS 2.X

The version 2.X is a separate project made from scratch and is closed source.


Quick Reply
Message:

Thread Tools