This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - LukeZ
Pages: 1 ... 12 13 14 [15] 16 17 18 ... 78
211
« on: December 19, 2020, 12:56:55 PM »
If it is firing the repair signal then you probably have the Fight/Repair switch on the TCB set to Repair, move it to the Fight position.
Also, note that Input A is for a physical switch attached to the TCB, not a switch on your transmitter. I doubt this is what you want, setup your functions so they are assigned to transmitter triggers.
212
« on: December 18, 2020, 09:16:14 PM »
Hi Neil, the one thing I see off the bat is that you have both the cannon fire and machine gun fire commands assigned to Aux Channel 2 Position 2.
I'm not able to test right at this moment but I'm assuming there is a conflict when it tries to fire both at the same instant.
I often put cannon and machine gun on the same physical switch, but this really works better with a 3-position switch, rather than a 2 position as you have done it. Your transmitter has some 3-position switches so you may want to use one of those. The setup would then be:
Position 1: Machine gun fire
Position 2: Machine gun stop (this will be the middle position of the switch)
Position 3: Cannon fire
In this way, when the switch is in the middle position nothing happens. When you flip the switch one direction the machine gun fires, when you flip it the other direction the cannon fires. If you don't like the direction that you have to move the switch just flip position 1 and 3 or else reverse the channel.
This may or may not fix your issue but I'd give it a try and see.
213
« on: December 16, 2020, 01:57:16 PM »
Hi Paul, the first thing we should do is confirm that the TCB is correctly reading the signal from your receiver. If the red and green LEDs on the TCB flash non stop that indicates the receiver is not being detected.
You can also open a Snoop connection in OP Config on the Firmware tab (connect your TCB to the computer, select the correct COM Port, then click "Snoop"). The Snoop connection will give you a lot of information about what is going on inside the TCB, and it will also tell you if there is a problem reading the receiver.
If the TCB is reading your receiver ok, then there is something else going on but your description doesn't say exactly what is happening. Does the "Read Radio" not work at all? Does it work, but your channels are not matched correctly? I don't know what exact problem you are experiencing. If you can put a short video on YouTube that might help.
Hopefully one of our German users will arrive shortly to also give assistance.
214
« on: December 16, 2020, 12:08:28 PM »
Anyway, I was checking back daily expecting that a response to a post that I had made would be flagged. Hi Eric, if you click the "Notify" button at the top of a thread the forum will send you an email when a new post is made, that way you don't have to keep manually coming back and checking. There are further user-specific Notification settings if you go to your Account Settings and under "Modify Profile" go to the "Notifications" section. 
215
« on: December 08, 2020, 11:42:03 AM »
Hi Osika, thanks for reporting back. Getting one pin off on one of the servo connections will definitely cause a problem! I'm glad that's all it was.
You still have the one board that is overheating all the time and that sounds like a Hobby King issue but it's good to know that is an isolated case and the other boards are working as they should.
216
« on: November 30, 2020, 12:59:42 PM »
You seem to have figured it out! You are correct, for the Benedini Mini the 2nd machine gun sound will go into User Sound 3 (slot 11) but then of course you lose that user sound.
217
« on: November 30, 2020, 12:57:51 PM »
Ok, I understand now. There is of course no way to print the pin in free air, but I gather that it is "attached" to the tread segments only at a very small point which can be broken after printing such that the tread segments then move freely. I can see there is some trial and error involved in getting it all to work but you are making good progress!
218
« on: November 30, 2020, 12:28:48 PM »
Luke- I have attached the platform.txt files for both my 1.8.13 and 1.8.5 IDE's. Hi Eric, I'm back but still in the process of digging out from the backlog of emails and stuff at my job, so I have not gotten much work done but I can at least respond to your posts! I checked out the two platform files you posted and I really don't see any differences in the relevant sections, but it was worth the check. I am happy to inform you that I am now able to compile the TankIR sketch with it working on both sending and receiving IR shells (screenshot attached to unnecessarily provide proof). I went ahead and uninstalled the Arduino IDE on my other laptop (laptop B) and reinstalled it letting it choose the install directory and use all default settings. The compiler reported:
“Sketch uses 24284 bytes (75%) of program storage space. Maximum is 32256 bytes.
Global variables use 1462 bytes (71%) of dynamic memory, leaving 586 bytes for local variables. Maximum is 2048 bytes.”
The net result of all of this is: TankIR needs to compile on Arduino IDE 1.8.5 with the installation being done using all default settings. I'm thinking that there were enough changes made to the compiler between 1.8.5 and 1.8.13 that the memory usage became much greater and the resulting low memory disallows properly registering a (Tamiya 1/35th) IR shell hit. This is good news and thanks for being persistent. However there definitely is something weird going on because the same code should really compile to roughly the same size and in this case the difference between IDEs is not even close. I will need to do some more research and probably post a help request over at the Arduino forums, but I really would like to get to the bottom of this. Whenever I do, I will report back here what I find. From my side I got what is probably the more difficult part of the ATTiny85 battle system working. It is now able to successfully fire an IR round at my Tamiya 1/35th Panther and have it cause damage. I've included a .zip file of the video I shot of the circuit in action and also included some pictures of the breadboarded circuit. I cannot say “Thanks” enough to Luke for his help. Although the code for the ATTiny85 doesn’t include any code from the TankIR implementation it was Lukes sharing his knowledge of the Tamiya 1/35th IR protocol which made it possible.
I’m still a relative newb as far as forum etiquette goes. I’m thinking this ATTiny project should perhaps be moved to it’s own topic, if it even belongs on OpenPanzer at all as it’s not an OpenPanzer offering. I’d welcome a response from anyone reading this who may provide some enlightenment to me. Your ATtiny85 project is very interesting and I'm happy for you to talk about it here. This forum section we're in right now is called "Other Open Source Projects" and that was exactly the intention, to give a place for people to talk about their own creations. If you want to share more details about it then I agree a dedicated thread in this same subforum would be a good idea, since no one will think to look for it in this thread. But you are not breaking any etiquette rules and I welcome your contribution!
219
« on: November 30, 2020, 12:11:06 PM »
Hi Osika, sorry for the slow reply. Jürgen is correct, there is almost certainly a short on the board. The most common place for this to happen is between adjacent pins on the processor chip. If you have a magnifying glass you can examine all around the processor and maybe you will see something obvious, but the pins are so small it is not always possible to see even if there is a short. If you do find one, then it is possible to correct it with a fine-tipped soldering iron and some flux, but again this needs to be something you are comfortable with.
220
« on: November 18, 2020, 11:33:24 AM »
Hi CodeWarrior - thanks for reporting back, it seems you have pinpointed where the problem must lie, and that is something to do with a difference between my IDE and yours. You asked why I didn't use the most recent IDE for development, but probably several years ago when I posted the TankIR project 1.8.5 was about the most recent. But they release new versions all the time, and quite frequently code that worked on one version won't even compile on a later version, or have other issues as you have discovered, so if I get something working I rarely have much of an incentive to go back and break it. But the strange thing this time is that you've tried IDE 1.8.5 and it doesn't seem to have made a difference as to how much memory the sketch takes when compiled (for you at least). I would be curious to see a file from your computer, it is called "platform.txt" and should be located here: YourArduinoInstallDirectory\hardware\arduino\avr\platform.txt If you could post that text file here I will take a look at it, and see if it matches mine in terms of Link Time Optimization (LTO) settings. You asked if anyone else had used this project - WibblyWobbly at RC Tank Warfare is the one who has had the most experience with it, he has a thread here which you may have already seen. I can also do some testing on my end and try to install the latest IDE and tinker around and see what I can discover. Ideally we would like to get this to compile in a functional manner with the latest version, now we know there is a problem. Unfortunately at the present moment I am in the midst of moving across the globe and I won't be to my new place until next week, but then there is Thanksgiving, so I can't promise I'll have time to look at this in more depth until after the holiday. However I haven't forgotten about this and I would like to get it sorted just for my own peace of mind, so I will definitely return to this topic when the dust has cleared.
221
« on: November 14, 2020, 12:05:19 PM »
I’m wondering if there may have been changes made to the Arduino IDE which somehow altered the manner in which the code compiles. It may be hard to see in the screenshot- I am using version 1.8.13 of the Arduino IDE. I started thinking the same thing after I posted earlier. Since you haven't changed anything else, the only difference must be the IDE. I am using 1.8.5 which is actually prior to 1.8.13. I've posted below a compiled version of the code from my IDE which only uses 71% of dynamic memory, and I changed the IR type to IR_TAMIYA_35. Can you give this one a test and see if it works? You can flash a hex file to your UNO using OP Config, on the Firmware tab select "Generic ATmega328" and then click the "Use your own Hex" button to select this file, then the "Flash" button to write it to your Arduino.
222
« on: November 13, 2020, 03:36:51 PM »
Ok, I see the changes I suggested weren't sufficient, if it had worked it would have given us even more information about what exactly is causing the decoder to fail to identify the signal, but it would not have changed any inherent ability. However, this comment caught my attention: I am a bit concerned about the statement from the compiler indicating:
“Sketch uses 25100 bytes (77%) of program storage space. Maximum is 32256 bytes.
Global variables use 1864 bytes (91%) of dynamic memory, leaving 184 bytes for local variables. Maximum is 2048 bytes.
Low memory available, stability problems may occur.” In fact that should not happen, and to avoid that very situation is why we only decode the first 3 bytes of the 1/35th signal. Did you perhaps change the value of RAWBUF around line 246 in IRLib.h? That is the only thing I can think of that would blow up the global variable allocation (the value of RAWBUF should be 51). In fact the sketch should compile with something around 1,462 bytes of dynamic memory, around 71% of the total, not 91%. Here is what I would suggest next - redownload the firmware from GitHub and start again clean, change only the IR_FIRE_PROTOCOL to IR_TAMIYA_35 in the A_Setup.h file, and try again and see what happens. If it still doesn't work, I will give you a sketch with the extra debugging options hopefully enabled this time.
223
« on: November 12, 2020, 01:54:44 PM »
Good progress Joe. But I have been quite stumped about your "print in place tracks" and have tried to figure it out for myself, to no avail, so now I will ask. Are you not using a metal pin to join each track segment? I saw the picture you posted earlier of a series of track segments being printed at once, but that was early in the process, after only a few layers, and as yet there is no hinge-pin visible.
It is beyond my ability to imagine how you could print a "pin" inside a floating hole to link the segments. Can you explain your wizardry further? It might help some others who are printing tracks!
224
« on: November 12, 2020, 01:46:53 PM »
Ok, you have made good progress. We are now halfway there! Yes, the 3.3 ohm resistor is very low, but we really have to overdrive the LED in order to get any range. I have found since the signal is so brief the LED can survive it quite well.
Now for receiving. In fact what you have reported tells me that some things are working as they should. It is actually as designed that the firmware seems to quit reading after the 50th bit, this limit is set by the RAWBUF define in the IRLib.h file (around line 247, there are some comments that go with it). You also found earlier some comments on how we send the 1/35 Tamiya signal - there is also a discussion on how we decode it, starting around line 378 in the IRLib.cpp file. You will see that for decoding of this particular signal, which is really quite different from the one all other models use (including Tamiya in 1/16th scale), we actually only read the first 3 bytes (no other protocol has those same first 3, or even the same receiving pattern, so we are not going to confuse it with something else). As you found with your Excel work, the firmware is actually detecting the first three bytes we would expect: 199, 242, 192
So we can rule out hardware issues, the Arduino is reading the signal from your Panther just fine, the issue is with decoding. I've spent some time refreshing my memory about what I wrote all those years ago, but I don't see any obvious problems with the code. The debug dump that you posted was exactly what we expect and it should have recognized it.
Let's try an even more detailed debugging routine. In file "IRLib.h" at or around line 52, you will see this line, which is also commented out:
// #define IRLIB_TRACE
Let's uncomment that, and also change it because it should be named this instead (so basically just replace that line with the following):
#define OP_IRLib_TRACE
Let's also change that dump test that we already uncommented earlier. This is what you had uncommented in "Tank.cpp" at around line 315:
IR_Decoder.decode();
Serial.print(F("Decoded: ")); Serial.print(ptrIRName(IR_Decoder.decode_type)); Serial.print(F(" Value: ")); Serial.println(IR_Decoder.value);
IR_Decoder.DumpResults();
Let's change that first line to this:
IR_Decoder.decode(BattleSettings.IR_FireProtocol);
This way it doesn't try to run through every possible protocol but only checks for the Tamiya 1/35 signal, since we already know that's what we're sending it.
Now give your Arduino a hit from your Panther and let us see what the Serial Monitor shows us...
225
« on: November 09, 2020, 12:48:35 PM »
Ok, you have made good progress already! It seems you have almost completely confirmed the similarity of the signals, which is good. The marks and spaces you have measured correspond exactly with what I have measured, and with each other.
There is some debugging code including in the TankIR project, if you uncomment these lines at around line 315 in the "Tank.cpp" file:
IR_Decoder.decode();
Serial.print(F("Decoded: ")); Serial.print(ptrIRName(IR_Decoder.decode_type)); Serial.print(F(" Value: ")); Serial.println(IR_Decoder.value);
IR_Decoder.DumpResults();
It might help you see the full signal coming in from the Tamiya tank, or whether anything is being received or not. But I feel quite certain, as you surmised, that in fact the signals are no doubt the same for all 8 bytes, if you have already confirmed the first 6 (and I confirmed all 8 once upon a time!)
I'm inclined to think you might have a hardware or wiring problem since the firmware seems to be working correctly. I would double-check that you have the IR connected to the right pins, etc... (Use the camera trick to confirm that the IR is indeed transmitting). What IR transmitter LED and receiver are you using for the Arduino side - is it 1/16th Tamiya gear, Taigen, something else?
PS: In fact the 2560 (Mega) boards and the UNO (and other variants) use a different microprocessor, the former use the ATmega2560 chip and the latter the ATmega328. Of course either one can work, we use the ATmega2560 on the TCB, and the Uno for the standalone IR code. If the standalone IR code compiles on the 2560 board, that is a coincidence! Anyway, I'm sure your clone Uno is fine, I have used several without problems, and we can see from your capture that the firmware is running correctly.
Pages: 1 ... 12 13 14 [15] 16 17 18 ... 78
|
Show Posts