Advanced Search

Thank you very much for responding to help!

I take the data from the transmitter, since it is in it that the microcontroller is unknown to me, so I cannot control it.

Unfortunately, I don’t know anything about time, I don’t have enough knowledge in this area and the datasheet doesn’t really help me in this either, I commented out the data sending in the sketch, since there is no information yet what exactly I should send, but what I sent without result. In the arduino sketch, I can make delays by doing millis or doing micros, now I just need to understand when to do it.

If I understand correctly, then the data transmitted between devices is recorded in register 50, the so-called FIFO, if there is data in this register, the receiver receives it and clears the register, and then you can either write new data to this register and transfer it, or simply go into receive mode and wait for new data.

I will try to send the same bytes that I received and see what happens, if I understand correctly, a delay of 800 microseconds is needed? Is this delay since the data was received? And it turns out that the data that I receive is not correct at all? My first assumption was that the remote sends data from the throttle and steering, then the remote waits for a confirmation of receipt and sends new data from the throttle and steering, but since I did not send the confirmation to it, it resends the same data.

I will try to read the SPI data in another version of the program and attach it here.

The following question is also of interest, in register 50, into which data is written and read, there is the first byte that does not seem to change 0x06, and in the datasheet there is a mention that the first byte of the payload indicates the length of the payload, in my case it is 6 bytes , and then everything seems to converge, 6 bytes go. Did I understand the datasheet and the received data correctly or am I mistaken?
In arduino, when outputting to the port monitor, this very first byte is not displayed, apparently in the sketch it is automatically discarded and I see only the last 6 bytes.

0x32 0x06 0x24 0x0B 0xDE 0x6A 0x45 0x05

It is also interesting what kind of register is 0xB0, into which 0x00 0x00 are written, nothing is said about it in the datasheet.

And while writing to 0xB0, perhaps not writing, I don’t know how to call it correctly, writing or accessing the register, data comes in the opposite direction at the same time. Perhaps it was necessary to indicate in the first post that all the registers and data in them I cited are from the MOSI bus, that is, from the microcontroller to the LT98XX transmitter.

When writing to registers 0x34, 0x32, 0x07, the following data always comes in the opposite direction 0x01 0x01 0x01, when register 0xB0 is accessed, different data comes in the opposite direction, for example:


Noticed the following:
When 7 is accessed by MOSI to 0xB0 0x00 0x00 on MISO is always 0x01 0x01 0x40
When 1, 2, 3, 5, 6 are accessed by MOSHI to 0xB0 0x00 0x00 on miso 3 bytes is always the same

You're doing the right things. Just receiving the data is good progress. I don't know the LT89xx nor much about Arduino but can give some general help.

Are you taking the SPI data from the transmitter (controller) or the receiver (vehicle)? Knowing this will help interpret the data.

In these protocols the timing is important. In the Arduino sketch the (commented out) transmit is done immediately after data is received. From the SPI capture it looks like the reply is sent about 800us after the end of receiving the data. This timing needs to be replicated.

You're right that the reply is not the same data that's received. Send back the same bytes that are in the SPI capture replies. Looking at the SPI data is easier after the data is exported, but for some reason when I export the capture (using logic 2.4.6) the packet ID is always zero. This may be a bug in the analyzer. Can you make a capture using version 1 of the logic analyzer software because I know that analyzer works. The attached Ruby script will format the exported data nicely but needs valid packet IDs.

edit: it's not a bug, it's a "feature" of the v2 software. A high-level analyzer must be loaded to frame the SPI data, but that data can't be exported that I can find.

Hello!

Please help with connecting two LT89XX chips

I'm new at this, so please don't be too hard on me.

There is an unknown control panel from the machine, it works on an unknown microcontroller (16-foot microcircuit with the following power supply: pin 5 - GND, pin 12 - +3.3 volts. The rest of the legs are occupied Gas, steering wheel, etc.


When the remote control is turned on, the remote control is in the device binding mode, which is signaled by alternately flashing LEDs.

At first I tried to scan the signal over the air using the NRF24, but it didn’t work out for me, I managed to find out only on which channels the remote control transmits the signal.

Next, I ordered the LT89XX chip as an XY-WA module for Arduino.

With the help of a logic analyzer, I connected to the SPI of the console and read into which registers and what was written. I compared it with the datasheet and made changes to the arduino sketch written for the LT89XX, writing the same values ​​to the registers as in the remote control.

Next, I launched the remote and the receiver and received data on the serial port, but this data is static and apparently does not relate to the data that the remote should send when you press the gas and steer. The remote also did not exit the binding mode.

I'm guessing I have to send something to the remote for the binding to happen, but I can't figure out what I should send. When I try to send what the remote control sent me, the remote control disables the binding mode (Perhaps it just turns off the indication or goes to sleep), but I don’t receive anything else from the remote control to the serial port. And the values transmitted by SPI to register 50 are changed to new ones.

The channel is also constantly changing, in increments of 20 units. For example: It starts from channel 10, then 30, then 50, then 70 and again channel 10.




After the initialization of the LT89XX, the following happens, this is written to registers unknown to me via SPI:
0x88 0x00 0x00, 0xAC 0x00 0x00, 0xAD 0xFF 0xFF, 0xB2 0x00 0x00, 0x34 0x80 0x80.

Further, the following is written in register 50:
0x32 0x06 0x24 0x0B 0xDE 0x6A 0x45 0x05

Almost the same I get in the serial port, only without 0x06
Packet read OK
Data 0 = 36 | Data 1 = 11 | Data 2 = 222 | Data 3 = 106 | Data 4 = 69 | Data 5 = 5

Next, the channel changes by writing to the register 7 new data
0x07 0x01 0x1E

And 7 times there is a record in the register 0xB0
0xB0 0x00 0x00 (x7 times)

After it all starts with a new entry in register 0x34
0x34 0x80 0x80

And so endlessly.

If I send to bullets what he sent me or part of what he sent me, then the data in register 7 and register 50 change.

New values are already being written to register 50
0x32 0x06 0x80 0x7F 0xFE 0xFF 0x00 0x06
Data 0 = 128 | Data 1 = 127 | Data 2 = 254 | Data 3 = 255 | Data 4 = 0 | Data 5 = 6

Channels 10, 30, 50, and 70 are changed to other channels, such as 21, 41, 61, and 248, and the binding indication is turned off, but no data is sent to the serial port anymore.

Below I have attached a datasheet, and a capture from saleae logic.

I do not know if I was able to describe correctly all the actions and processes that I performed and received, if additional information is needed, I am ready to provide everything.

If you have the opportunity and time to help me, I will be very grateful. I just don't know where to go next.

Sketch Arduino





The Session 0.txt file needs to change the extension to sal

You're welcome!

Thanks for your efforts. It seems you are the only active developer working on new builds.

ouch. I mentioned gimbal pots as the TX8 looks like a T8SG clone with the LCD screen. Might be able to fix with new hall sensors and maybe power regulator(s).

Nope, that has just killed my TX, bummer

So, it would work correctly, if I simply swap the plus and ground cable on the hall sensors?

Sounds to me like those two channels have the gimbal pots backwards. Switching the wiring should work.

I wonder if all TX8's are like that.

I own a Radiomaster TX8 and a Jumper T8SG v2, both running the same firmware.
The Jumper acts normal, I have to reverse both rudder and aileron for DSMX, trim works a intended.
On the Radiomaster, reversing those channel is not needed, but instead the trims are reversed.

Have I missed a setting in Deviationtx, or can this be fixed by simply changing the wiring of those 2 channels on the gimbal-plugs?

Deviation links

Fixed crsf menu STRING parameter handling. Does not affect ELRS because it doesn't use this parameter type, but TBS modules use it for passwords.

That's correct. The unselected radios will not transmit. Just have to be careful not to select a protocol that uses a module that does not have an antenna connected.

You're welcome, and thanks!

I have just added swivel antennas to the Devo7e, and my question is if it's safe to remove the antennas from unselected modules. I believe that while the modules are disabled they don't transmit any power. So it seems to be safe to remove the antennas.

Please, can I get a confirmation on that. Thanks

No issue at all. Thanks Hexfet, your work has allowed the Deviation program to live on.

The dfu in the t8sg_v2 archive is zero length. Sorry about that. My build box has been crashing and must've interrupted that build.

I've rebuilt and re-uploaded. New download link is here

The Deviation uploader should automatically extract the DFU from zip file. However, I also extracted and tried to load the DFU , did not work.

rc manic wrote: Deviation uploader 0.9.0 will not unpack the newest T8SG-V2 zip file. Downloaded several times with same result.
Still unpacks all previous firmware builds. Also unpacks newest T8SG-V2-Plus and 7e-256 files, just not T8SG-V2
Anyone else having same issue?

Are you using the DFU file inside to upgrade? That should work for firmware update.

Deviation uploader 0.9.0 will not unpack the newest T8SG-V2 zip file. Downloaded several times with same result.
Still unpacks all previous firmware builds. Also unpacks newest T8SG-V2-Plus and 7e-256 files, just not T8SG-V2
Anyone else having same issue?

I downloaded the latest firmware 3.01 for DX8 and flashed it, now the question about the receiver IRangeX RM601 2.4G 7CH is available only the de pinned version if I buy it here , where can I get a pad with pins that I will solder myself

or as an alternative, what other DSM-2 receiver can I buy advise that it works stably and reliably up to 300m