Welcome! Log In Create A New Profile

Advanced

Jakadofsky PRO ECU / RPM Sensor

Posted by rotorspin 
Jakadofsky PRO ECU / RPM Sensor
May 12, 2020 12:58PM
Hi there

I have dual NEO's (pro) in Master/Slave, Vbar Touch and a Jakadofsky Pro5000 Turbine 1:4 scale heli

Set the Throttle control (Off,Idle,On) all works fine, also with your help the swash is all setup.

I have 2 questions

1. Can you recommend an RPM sensor? I see you say it supports Optical and Magnetic (Optical is my preference) but can I use any?
2. is there a way of getting telemetry out of the Pro ECU either to feed RPM or other info?

Thank you as always in advance

John
Re: Jakadofsky PRO ECU / RPM Sensor
May 12, 2020 02:02PM
Hi John,

1. you can use any. Afaik there is no sensor known which would not work, signal wise, but of course some are easier to set up (magnet) than others (optical). Just mind the operating voltage, it must match yours on the model, else you would need a regulator or voltage divider.

2. no. We've been talking to turbine manufacturers since the beginning of (VBar Control) time, but JetCat is the first to implement it, and even they still have to cover some space to get there.

Best,

Eddi

Born to fly ...
forced to work.



Edited 1 time(s). Last edit at 05/12/2020 02:03PM by Eddi E. aus G..
Re: Jakadofsky PRO ECU / RPM Sensor
May 12, 2020 02:34PM
ok thank you Eddi

I see there is a module call VSpeak. They say their module cannot communicate with the NEO, however it appears to support far more basic systems. Do you think it would be possible via the VSpeak module?

http://www.vspeak-modell.de/en/ecu-converter/jakadofsky
Re: Jakadofsky PRO ECU / RPM Sensor
May 12, 2020 04:56PM
Hi John,

I'm afraid, no. Our telemetry requires a unique ID (so different items can be id'd, different ESCs, GPS, Temperature, Speed, Battery ID etc.) and a bidirectional protocol, else we could not do it the way we do it.

Black boxes like VSpeak can't accomplish that, they more or less process third party data streams and output a harmonized data stream, which other systems decode, which do not yet have a sophisticated bus system like we do.

And because you can use our telemetry data also for control inputs (via Macrocells), we do not want a black box where you can connect whatever you want, outputting whatever data there come. False or unknown/uncontrolled data could mess things up. Where it's only for display, and where there's nothing else, OK, but it doesn't work for us :-/

Kind regards

Eddi

Born to fly ...
forced to work.
Sorry, only registered users may post in this forum.

Click here to login