Thread Tools
Nov 30, 2021, 03:54 AM
OlliW
Thread OP
first off, unfortunately many of the v1.3x boards you can buy today seem to be quite low quality. It seems to me that it's a long time ago that boards were manufactured and they are selling off what they still have lying around, including those with quality issues. One also can find boards which do not use the original ST chips, which also had caused issues in the past.

second, it is always possible to kill these boards by improper electronics/voltages attached to it. They can be very long living (it's long time ago that I killed one myself) - but only (!) then handled with their limitations in mind.

So, disconnect everything from the board except a usb plug to provide power to the board. Then do a full erase of the chip and reflash the firmware (the full erase is important). If the board doesn't come up then with blinking leds I'm afraid it is probably dead.
Sign up now
to remove ads between posts
Nov 30, 2021, 08:12 AM
Registered User
Hi OlliW,

Thank you for the reply. Here are a few points which I like to tell:

1. Yes the board can be the one with a fake STM32 chip.

2. I can assure you that the board doesn't get destroyed because of improper voltage. Just a day before it was working completely fine and when I plugged it again, it got stuck. There was no hardware/software change at all.

3. I have tried doing a "full chip erase" and "reflashing", but still the same result.

4. And the main point which justifies the MCU being active is that when I plug in the USB, I see the green LED blinking 3-4 times, and then both the green and red LEDs are constantly on. In this condition, even USB doesn't get detected, since the board is "stuck". But as soon as I connect STlink, it shows MCU core as "halted" and as soon as I click "run" or "core reset", the board proceeds normally and is also able to read/write via USB now in the configurator.

So the MCU is working, it's just that it ends up in a "halted" state due to some reason.
Maybe it could be due to a fake STM chip, or some rare software case, but that can't be confirmed.

Thanks,
Divyanshu
Nov 30, 2021, 09:00 AM
OlliW
Thread OP
to 2.: this argument is a typical fallacy. The fact that one could switch it on 15 times doesn't mean all is ok and it will survive the 16th switch on. E.g. SR's can produce voltage spikes at startup, and depending on its level it is a mere question of chance when things will die.

so, from your text it appears to me that your observation is that when you full erase, reflash, and plug in the usb and ONLY the usb, you do see led lights flashing for some time before it "stops".

I would continue to believe that your mcu got killed. Note that "killed" does not necessarily mean that it doesn't do anything at all, it often also means it's behaving odd. E.g. if one pin gets destryoed it may destroy some peripherals insiode, but not all parts of the chip. Not unheard of.
(if you want some f103rc with just few pins killed, I can donate some to you LOL)

> Maybe it could be due to ... some rare software case

you safely can rule out this. The v0.96 firmware is around for ages and its issues known. You of course still can argue "rare" can mean really rare and you made the lucky punch, but the chances are that you get on a wrong track.

The error pattern you describe doesn't trigger anything in my head besides "killed mcu". That's all I can do, to share my honest opinion.

maybe someone else here has a better idea what could be up
Nov 30, 2021, 09:33 AM
Registered User
Thank you OlliW for your reply.

Yes, I also think that some portion of the MCU is damaged.

However let me describe the things I observed in detail, so you can also understand:

> When I power up the board (either via USB, STLINK, or 12V BEC) what I see is that the green LED blinks 3-4 times, and then both the green and red LEDs are continuously glowing.

> The program doesn't seem to proceed from this point. Also, the USB can't connect at this point, even if the board is powered from STlink also, at the same time.

> However, at this point if I see from STlink, the MCU core gives "halted" status. So I remove the USB cable and use only the STlink, and do a "erase chip" and reflash it.

> Now again, if I repower the chip either from USB, Stlink, 12V BEC, the green LED blinks 3-4 times and then both the green and red LEDs are continuously on, and USB is also unable to connect. So I remove the USB cable and use only the STlink, and when I click on "run" or "core reset", then I can see that the board instantly proceeds and both the green and red leds start blinking, as when they do on USB connection. Now while being connected to STlink, if I also connect the USB, then the configurator can read and write to the device normally.

> But as soon as I remove all the power from the board and repower (either from USB, STlink, 12V BEC), the same thing happens, i.e., the green led blinks 3-4 times, and both LEDs gets stuck, and nothing proceeds.

> However instead of clicking the "run" or "core reset" buttons, if I only connect and disconnect the STlink from STlink utility, then also the board proceeds forward.

Thanks,
Divyanshu
Dec 07, 2021, 10:31 AM
Registered User

Getting Gimbal Angles in Mission Planner with v0.96 Firmware


Hi,

I am using a Storm32 v1.31 board with an I2C IMU using v0.96 firmware.
With this setup, is it possible to read the live gimbal pitch and roll angles in the mission planner via Mavlink?
This is needed so I can calculate the GPS coordinates at which the camera is looking at, by using the gimbal pitch angle, drone's GPS coordinates, altitude, and heading.
To do this, I need to find a way to get the live pitch angle of the gimbal on the mission planner. Please help.

Thanks,
Divyanshu
Last edited by harkhka; Dec 07, 2021 at 10:37 AM.
Dec 08, 2021, 01:34 AM
OlliW
Thread OP
hey Divyanshu

first off, please understand that you are using a firmware which is many years old, and I myself for instance can't remember the details of what is was able off and what not, and given it is that outdated I have also no interest to look again into it and figure out what it was able of an what not. The best source of info is the old wiki: http://www.olliw.eu/storm32bgc-v1-wiki/Main_Page. And all I do is look at it.

According to it you can activate the ATTITUDE message, which gives you the live angles (at 2 Hz).

If you are using a flight controller like ardupilot however the larger problem will be how to get that mavlink message to the ground such that you can use it. Also note that Ardupilot has a STorM32 serial mount, which makes Ardupilot sending the live angles via mavlink to the ground. I have never used or tested it, but it is supposed to work with 0.96, and I think that this is probably the best option for you. If this is not working for you, e.g. because you need the angles at higher rate, you'll need to throw in an Ardunio or alike and read the angles yourself using the RC commands.

cheers
Dec 08, 2021, 03:36 AM
Registered User
Hi OlliW,

Thank you for your reply. Really Appreciate it.
If you could please answer a few more of my doubts, then that'd make my day and clear everything.

1. If I use Ardupilot with StorM32 serial mount / StorM32 Mavlink, then can I get the live angles to the ground station at 2Hz? This refresh rate is fine for my application. Also, can this stream be enabled/changed by using the SR1_x parameters, since these parameters are used for enabling messages to GCS?

2. If I use Betapilot, then can things get any better with my setup using v0.96?

3. Let's say the worst case I have to put in an Arduino, then what steps should I follow to enable message exchange Ardupilot? I am familiar with IMU calculation and PIDs, as I have designed my own FC in the past (www.divyanshu-harkhka.com/flight-controller), so the only bottleneck for me in using an Arduino is how to talk with the FC and getting the stream on GCS.

Waiting for your reply.

Thanks,
Divyanshu
Dec 08, 2021, 04:15 AM
OlliW
Thread OP
1. I cannot tell you really, since I never used or tried to use ArduPilot with that mount. I would think it should do it at least with 2 Hz, maybe even more. If it can be enabled/disabled with SRx you really need to research yourself. sorry.

2. no. BetaPilot is made to work with the latest and greatest

3. that's really not easy to answer, since there are many ways of doing it, and it also very much depends on the particular setup at hand. If you want to do the processing om the ground, and need to send the data via mavlink, it's probably not so easy,as you would need to communicate on one uart with the STorM32 and on another uart build a MAVLink interface. If you have a companion which runs already a mavlink router it should be easier. If you run latest ArduPilot you might even be able to do it with an ardupilot onboard lua script. and so on. My feeling is you should try ArduPilots STorM32 serial mount, and if this isn't working out for you I guess you will need to reconsider the basic approach, i.e., have to do more efforts. You are not dealing with only STorM32, but with the whole MAVlink network, and thus need to get all pieces to work together, and if none of the pieces is made for it you may not find a simple solution.
Dec 08, 2021, 09:00 AM
Registered User
Thanks OlliW for the reply.
To take advantage of Betapilot, will an NT module with a v1.31 board suffice?

I was also thinking to make a simple Arduino board with basic servo motors to adjust the camera angle. In this setup, can you guide me on how to communicate the gimbal angle calculated on the Arduino board, directly to the Ardupilot, and then to the GCS?
Last edited by harkhka; Dec 08, 2021 at 09:06 AM.
Dec 08, 2021, 12:26 PM
OlliW
Thread OP
Quote:
Originally Posted by harkhka
To take advantage of Betapilot, will an NT module with a v1.31 board suffice?
yes
the v1.31 board has some limitations, see the (new) wiki, but with just one NT imu it works fine

Quote:
Originally Posted by harkhka
I was also thinking to make a simple Arduino board with basic servo motors to adjust the camera angle. In this setup, can you guide me on how to communicate the gimbal angle calculated on the Arduino board, directly to the Ardupilot, and then to the GCS?
I maybe could, but - frankly - I won't. This is a totally different setup and totally unrelated to STorM32. sorry, sir, not my cup of tea
Dec 08, 2021, 01:31 PM
Registered User

STorM32 In tea cup


This is my first Iteration of a 20x20mm dual driverNT module single sided so it can be stuck anywhere. (Not quite finished) On board 5V. Will be doing the BGC with onboard USB soon.
Dec 08, 2021, 01:52 PM
OlliW
Thread OP
fantastic
may I ask, what mcu this is? as much as I know the f103rc isn't available as qfn, and it isn't 36 pins anyways
I don't see there is a STorM32 firmware available for such a kind of chip, and on-board motor drives in particular
you are not expecting me to do a special designed firmware, are you?
Dec 08, 2021, 06:52 PM
Registered User
This is just a motor driver module, with 5v reg, the storm32 bgc board will be powered from this. It’s a take on the Triple micro version you did but adapted design for my micro gimbal.
The hard part was making it a 2 layer board and single sided but I think i got it now.
Dec 09, 2021, 03:09 AM
OlliW
Thread OP
oh .. ah .. oje oje ... I should have read what you said more carefully ... it is a motor module !! .. sorry sir for missing this

Dec 10, 2021, 02:48 AM
Registered User
Olli, curious to hear your thoughts: One feature I think is missing in the gui is being able to define what pwm range a feature should be activated. For example, I want stand-by to be activated only when aux-6 is in between 1700-2100. This has become pretty normal in most flight controller software and allows for often-needed flexibility:
  • Some cheaper radios don't allow you to reverse a switch. This would ensure users could still do so
  • Would allow for 3 position switches (found on most radios) to be used for multiple functions. Eg middle position: nothing, up: standby, down: re-center
  • The biggest problem I face is I don't have enough aux channels for the functions I need because each function requires its own aux channel. We are able to get around this issue with programs like betaflight and inav by using few aux channels to control many functions. This is done through some trickery with radios and the definable pwm ranges of each function. Here is a video which should give you an idea of what I'm talking about
    ALL MODES ON ONE CHANNEL | FrSky Taranis OpenTX Advanced Programming (22 min 28 sec)

Here's a list of functions that I believe should have definable pwm ranges:

Pan mode settings default, 1, 2, 3
Standby
Re-center camera
Camera control
Camera control 2
Script control 1, 2, 3, 4

I request this feature hoping it's not a horribly complicated matter and that it benefits most users. Certainly don't need any fancy gui sliders. Just two parameters per funtion: min and max pwm values to define the active range. Maybe this could be placed under the interface tab.
All the best


Quick Reply
Message:

Thread Tools