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 ... 23 24 25 [26] 27 28 29 ... 78
376
« on: November 17, 2019, 02:45:57 PM »
So I connected up my trusty Tektronix TAS 465 dual channel scope, (be kind as I think I use this thing once every 5 years). Channel one to the input to the inverter, and Channel two to the output. The input square wave is about 2.5v high, whereas the output is about twice that. So the transistor is amplifying the signal? I checked with both sets of resistors (6.8k/2.2k & 47k/10k) and the ouputs appear about the same. This signal is being inverted, just by too much??
Should I now go for the through hole equivalent of the BC848 (I think its a BC548)? That o-scope test hasn't told us anything. We are interested in whether the signal is being inverted, the absolute voltage levels are not of interest. No doubt your receiver is operating at 3.3v and the Mega is running at 5 volt so what appears to be an "amplification" is to be expected (nothing is really being "amplified" just translated). What you want to see on the oscilloscope is when the input to the transistor goes low the output goes high, and vice versa. That is inversion and that is the piece that you are trying to figure out. Sure, you can try the BC548, or just eliminate the inversion circuit all-together using the instructions in the link I provided as a test. EDIT: Actually, I'm willing to bet I know what your problem is. Note that the radio input signal gets routed to two pins on the Mega - Arduino pin 3 for PPM, and Arduino pin 15 for iBus/inverted SBus. Probably you have just routed the receiver to pin 3 and not also to 15.
377
« on: November 16, 2019, 08:01:40 PM »
I have ppm working fine from a 9x pwm xmtr through a converter to ppm. When I try hooking up the inverter, using a FrSky XSR receiver, no radio is detected (both from blinking leds, and from snooping 'waiting for radio'). So I tried the 9x with converter using the sbus output, still no go. When you say you tried using the "converter with the SBus output", do you mean you tried using the PWM-to-PPM converter on the SBus output? That will not work since the converter will only work with PWM input. But I do note that the XSR also has a P PM output. Since you know your Mega is reading PPM just fine, you could try connecting the PPM output of your XSR directly to the Mega, for that test you won't need the converter or the inverter. I wonder if it could be something as simple as the receiver just not being bound correctly to your transmitter module. Also note on the link I provided earlier they show where on the XSR you can tap into to get the uninverted SBus signal directly. You could try that as well, if it works then we know the issue is with the inverter transistor, if it doesn't then I would begin to suspect more strongly something with the receiver. I put a voltmeter from input to output on the inverter circuit, and get 3.27vdc, which to me seems that the signal is getting inverted? Am I right in thinking that? Is it perhaps that this transistor is too slow for the frequency of the sbus signal? I think there isn't much we can tell with just a voltmeter, the scope would tell us more, but I would try the easier tests above first.
378
« on: November 16, 2019, 08:17:28 AM »
The BC337 should work although I have not tested it personally, however there are accounts of others using it, see here. That guy used different resistor values than the TCB and you could try modifying yours to be closer to his, he used 6.8k and 2.2k instead of 47k and 10k so quite a bit lower. The 1.2 volt turn-on should not be a problem even if your receiver only manages to spit out a 3.3v signal, which is not unommon. You can also buy a pre-made inverter for cheap, but I'm not sure what the shipping would be. Here is also a page on how to tap into the uninverted signal on certain SBus receivers. I'm having a hard time identifying exactly the radio portion of the schematic you posted. The main thing to check is if you have the transistor wired correctly, it's easy to get the legs backwards as I know from experience. Keep me posted!
379
« on: November 02, 2019, 01:40:09 PM »
Well I'm glad that's all it was! So many times here on the forum, and to be honest in my own experience as well, it's the simple things that really bite you! 
380
« on: November 02, 2019, 12:56:30 PM »
Another thing to mention - your Mega boards obviously don't come with any firmware on them. You will not be able to connect with OP Config until you've flashed the TCB firmware to them, this can be done using the Flash utility in OP Config or it can also be done with the the Arduino IDE if you download the source code. Have you been able to successfully flash the firmware first?
381
« on: November 02, 2019, 12:10:23 PM »
There are two types of connection in OP Config - the first is what you are trying when you click the "Connect" button. The second is the Snoop connection and that is the equivalent of the Serial Monitor in the Arduino IDE (it just listens or "snoops" but doesn't actually communicate).
Have you tried just connecting with Snoop to see what it does? If it can connect via Snoop, while snooping you can then click the Connect button, and see if it will connect that way.
382
« on: October 25, 2019, 12:25:11 PM »
What can I say but that cheap stuff from China often comes with a hidden cost!
383
« on: October 23, 2019, 09:17:58 AM »
I think that the acceleration sound should change with frequency instead of just playing in the original sound. Have you tried this? I am trying to do this, but I have only little time. I am not sure I understand exactly what you are asking. But I will say, the current audio capabilities of the Teensy do not allow us to speed up or slow down a .wav file. If we want an acceleration sound that sounds faster, we have to create two sound files - one slow, one fast. Before that, I think I should have perfect hardware first. Light card is useful for tucks as there are always many lights on a truck.This well be a fully new design. You might also be interested in an earlier project of mine called Open Source Lights (OSL). It is not very sophisticated but it does have a lot of options for lights on cars/trucks. You can read about it here - Open Source Lights - Arduino based RC Light ControllerI think I have a bad programmer. So the Hex may not be on the TCB. The light don't work. So I have to buy a new one. Thank you for your suggestion.I will tell you if there is any progress. AVRDUDE should tell you (through the IDE or the command line, whichever one you are using) if the burn bootloader failed. But a bad programmer is very often a problem. I have used this one with success (set it to 5v). It's hard to tell exactly from your picture, but I don't see a USB connector. Did you go with your previous plan of using a separate board for the bootloader chip?
384
« on: October 22, 2019, 12:02:19 PM »
Hi Luck. I am very impressed with your work on the miniature sound card, excellent job. Are you use a 4-layer board? With the elimination of the Teensy and the reduction in size, production costs of such a board should be much more reasonable. I don't know if you have any contacts with Chinese manufacturing but there might be a greater willingness for someone to take this to market than the existing design. As for the TCB - yes, it does use a custom bootloader, I have attached it to this post along with some instructions if you want to use it. The main difference is that it has been reduced in size from the standard bootloader and it also permits flashing on an alternate serial port depending on the position of Dipswitch 5 (Arduino A12, ATmega2560 pin number 85, port K4). When this pin is held to Gnd the processor will accept firmware flashing through Serial 0 (USB on the stock TCB board), when held to +5v it will accept firmware flashing through Serial 1. However you can still use the stock Arduino bootloader since we usually don't need the alternate flashing port. Everyone here using off-the-shelf Arduino Megas are using the stock bootloader. You mention that you flashed the bootloader, but you didn't say whether you had flashed the firmware. After you burn the bootloader then flash the latest firmware. After both of those are done then you can try to connect. I don't know if you are having a problem at the firmware stage or the connecting stage. If you are having problems flashing the firmware, you can try to flash a simple test sketch from the Arduino IDE, something like blink an LED. See if the IDE has problems or not. For connecting, have you tried the alternate connection method where you connect first via Snoop, and once that has been established then click the Connect button? Let me know what you find and I will help you out.
385
« on: October 21, 2019, 09:39:24 AM »
Very good, I'm glad we got it sorted. This was a case where you wanted the computer to recognize 7 positions, but told it to expect only 6. I have done a similar thing many times and pulled my hair out until I finally realized I needed to tell my computer the truth.
Yes, no sending signal (neutal, 0) was still recognized like a signal. Even when completely normal this was something different, unexpected and new for me. It seems we can always learn something new... And it also seems once implemented I will need 13 positions instead of 12, Lol.
I don't want to be too pedantic but all this trouble will be wasted if we don't learn the correct lesson. There is no such thing as "no sending signal" unless you disconnect your receiver. There is also no such thing as sending "0" but even if there was, 0 is still a number and a value. What you call "neutral" we think of as stick center but neutral is only meaningful to humans, it is still a SIGNAL. All RC signals are represented by a number from 1000 to 2000 (in the old PWM days this was the actual length of the pulse in microseconds, with digital receivers it is just a number but they still use the same range of 1000 to 2000). No matter what number you send within that range, it is a number and it is a value. You originally told the TCB to expect 6 values but then you also sent it 1500 at the end and wondered why it was playing a sound. 1500 is a signal, it has a number, the TCB has to do something with it. Sending 1500 is not the same as "not sending anything," it is sending something. Just consider the case where you have a 3-position switch. The three positions will be 1000, 1500 and 2000. Should the TCB think that 1500 doesn't count and just ignore it? No, then you would not have the behavior of a 3-position switch, you would be cheated a whole position! So 1500 is a real signal and just as important as every other number from 1000 to 2000. I understand you wanted your switch to perform 6 actions, but nevertheless you were literally sending 7 positions to the TCB. So we needed to tell the TCB to expect 7 positions. I hope this is clear for anyone reading this in the future.
386
« on: October 20, 2019, 03:41:41 PM »
Very good, I'm glad we got it sorted. This was a case where you wanted the computer to recognize 7 positions, but told it to expect only 6. I have done a similar thing many times and pulled my hair out until I finally realized I needed to tell my computer the truth.
387
« on: October 19, 2019, 04:10:05 PM »
It sounds like your RUD switch doesn't only change the channel to the newly selected position of the 6-position switch, but when you move the RUD switch back, it changes it once again to something else (probably center, which the TCB interprets as position 3).
If possible, just have your RUD mix leave the output at whatever it is. For example, you move the 6-position switch to position 5, trigger it with the RUD switch, so now the channel output goes to position 5, and when you move the RUD switch up leave the output at position 5 until the next time you move it down.
Or, have the RUD mix change to the new position whether you move it up or down. When you go do, it selects the position, when you go up it selects the position. When you select a position you can just leave the RUD switch where it is until next time, then flip it the other way.
Or if a neutral position is required then you will need to create a 7 position switch in OP Config, since that reflects the reality you are transmitting - 6 selection positions plus 1 more position that you don't want to do anything with. In fact, if you really already are transmitting 7 positions then using a 6 position switch in OP Config would probably create even more problems such as the wrong sound being selected, or who knows. The positions are not going to match up so the behavior will be unpredictable.
The more I think about it the more it sounds to me like what you have is actually a 7 position switch.
388
« on: October 19, 2019, 03:02:46 PM »
There is a humorous comment that computer programmers will often make when their program isn't working correctly: "I wish my computer would do what I want it to do, not what I told it to do." I believe this is just such a case. I thought I understood your setup but you lose me when you talk about a "neutral" position. When you define a 6-position switch, there is only just that - 6 positions. The screenshots you posted show this correctly. There is nothing between 3 and 4, there is no "3.5" I don't know how you can get your 6-position switch to even sit between positions, but if you try, the TCB will select either 3 or 4 (it looks like it is leaning towards 3). If you need something between those two then you need to define a 7 position switch, however I don't know why that is necessary. When you flip the RUD switch down, it should play whatever is selected by your 6-position switch and the ELE combination. When you flip the RUD switch up, you want it to do nothing, but apparently it is triggering some position, which is an issue with your RUD mix. If you need an extra position that does nothing, define a 7-position switch. You will still get 6 sounds (1-3 and 5-7), so you aren't going to be missing any sounds. And you don't need to create a silent WAV file for position 4 (which will be the middle position), just don't assign position 4 to any function in OP Config. Then when position 4 is triggered, it will do nothing because you didn't tell OP Config to have it do anything. How do I personally trigger user sounds? Well first off I don't have time to even play with tanks, because I am too busy writing code for tanks. But if I do, I don't even use sound because I don't personally care for them. But if I do use sound, I don't need 12 sounds, so I can just assign them to a simple switch directly with no transmitter mixing. However I am certain you can get it to work but you need to understand exactly what your radio mix is doing. If the TCB is playing a sound when you don't want it to, that is because your transmitter is telling it to play that sound. You need to figure out why your transmitter is doing "what you told it to do" instead of what "you want it to do." 
389
« on: October 19, 2019, 01:40:28 PM »
The other thing I will add is that you don't need to flash new firmware unless an update has been released, and even then only if you need/want whatever new thing has been added in the latest release. Once you have a working firmware on the board, there is no need to update it.
When you do flash a new firmware it can erase all your prior saved settings. So it very well could be for example that you had engine start assigned to some switch but with the new firmware that has been removed and you need to re-create it.
You can always tell what settings the TCB thinks it has by connecting to OP Config and doing a read from device (green down arrow). Now look at the settings and especially the function triggers and see if they are what you expect. The same goes for your channel assignments. If they are not correct, you need to change them.
The way to avoid having to do this every time a new firmware is flashed is to save your settings to an OPZ file (in OP Config go to the File menu and select "Save Settings to File.")
Now if a firmware update does erase your settings, you just have to open that OPZ file (either double-click on it in Windows, or if OP Config is already go to the File menu and select "Import Settings.") Then write those settings to your TCB (using the blue up arrow).
But again, once you have your model working there is usually not a need to be re-flashing firmware. Of course you can always change the settings whenever you want, but that is just reading/writing to the device in OP Config, and does not involve flashing firmware.
390
« on: October 19, 2019, 01:24:47 PM »
Good, this sounded very much like a driver issue so I figured that would solve it. Can I assume that the 28/29 pins remain the same for the drive motors regardless of which mode the radio is in? Yes, that is correct. It doesn't care what mode your radio is in or what channel is what, so long as you map everything correctly in the Read Radio procedure. If you have the sticks correctly assigned to throttle and steering and you can see them moving in the correct direction when reading the radio, then you are good to go. Most likely you are missing something very simple like the engine hasn't been started. Using Snoop is the best tool to debug this. Can you start the engine and see that reflected in Snoop? After the engine is started, when you move the throttle forward does Snoop say you are moving forward? (You can also use the red/green LEDs on the board to confirm that movement is being commanded, see here). There may yet be a blown tx/rx chip on the 2560, if the tx signals aren't getting through the Arduino. I won't know until the new board arrives. I'm not sure exactly what you mean here, if you can flash firmware and read the radio then tx/rx to the Arduino are working fine. Serial communications aren't used for driving the ESCs, those are servo outputs. If you fry the ATmega2560 chip then it usually doesn't work at all, but in some cases it is possible to ruin isolated pins. However I haven't heard that you've done anything to damage the chip so far, sounds like you just had a Windows hangup with the USB driver.
Pages: 1 ... 23 24 25 [26] 27 28 29 ... 78
|
Show Posts