Back
[01:26:29] <clixxIO_> does anyone know much about frequency-counters on avr?
[01:27:42] <clixxIO_> mine is working ok, but just hunting for the-best solution
[01:27:45] <clixxIO_> https://plus.google.com/109366813998920635083/posts/DNoCzU3y6qs
[01:28:24] <clixxIO_> here's the library that I'm using :
http://www.avdweb.nl/arduino/hardware-interfacing/frequency-period-counter.html
[01:31:24] <w|zzy> http://www.youtube.com/playlist?list=PLD7F7ED1F3505D8D5 <-- check out #7 i think clixxIO_
[01:31:36] <w|zzy> Good series.. He also goes through freqency counter as part of their DMM lab
[01:32:29] <clixxIO_> I will probably watch them all - thanks
[01:32:48] <clixxIO_> the time is upon me to really learn everything I can about the attiny
[01:34:37] <clixxIO_> I'm probably going to have to write some custom-code, I realise that
[01:38:33] <clixxIO_> The thing i'd really like to do the most is put the attiny into sleep mode
[01:38:55] <clixxIO_> still hunting around for a solution to that
[01:41:55] <clixxIO_> w|zzy : what are you working on these days?
[01:42:01] <w|zzy> Finance.
[01:43:10] <clixxIO_> ah ok - very neccessary
[01:45:56] <w|zzy> Studying it at uni :P
[01:53:04] <clixxIO_> ah unfortunately I never got the opportunity to study at uni
[01:53:22] <clixxIO_> I did work at a university for a while
[01:53:43] <clixxIO_> so I'm mostly self-taught
[01:53:51] <w|zzy> you have to make your opportunities..
[01:54:01] <w|zzy> I work full time and study part time
[01:54:05] <clixxIO_> right
[01:54:29] <clixxIO_> I will be taking on investment later on in the year
[01:54:47] <clixxIO_> putting together a business plan and prospectus
[01:55:19] <clixxIO_> Australia is nice, but not really that supportive of electronics manufacturing
[01:56:05] <w|zzy> Cool stuff
[01:56:40] <clixxIO_> just trying to finish off my designs and marketing
[01:57:03] <clixxIO_> i have enjoyed working by myself on these things
[01:58:07] <clixxIO_> but off to get investment for a factory in thailand or malaysia
[01:58:43] <clixxIO_> maybe japan, we'll see
[03:46:58] <aep> wow, free EE lectures. thanks w|zzy
[03:47:44] <w|zzy> aep: Ive watched the first 10
[03:47:50] <w|zzy> They are very good.
[03:48:05] <aep> i wish udacity had an EE course. they rock
[03:48:09] <w|zzy> He doesn't screw around, is a good presenter and covers a lot of info.
[03:48:19] <w|zzy> ive only watched the first 12
[03:49:09] <aep> actually:
https://www.coursera.org/course/eefun
[03:52:13] <aep> never mind, that's just university bla bla. no real world application
[03:53:36] * inflex goes chasing 13.3" eInk displays
[03:54:29] <jerkey> inflex if you find some let me know
[04:06:16] <inflex> jerkey: they're manufactured, as there's a few new devices coming otu with them... and there was an indiegogo project to produce the boards to drive them
[04:06:57] <inflex> jerkey: wanting one because I want to make a wordprocessing system for my wife, who has a lot of trouble working on traditional screens due to the transmitted light
[04:08:51] <inflex> jerkey: (she's a novelist)
[04:11:54] <jerkey> inflex one could take a regular LCD screen and construct a lightbox behind it to make its light come from the ambient environment. would that be an improvement?
[04:16:36] <inflex> jerkey: I don't imagine so. eInk does have a particularly good readability with low eye strain we've found
[04:16:55] <inflex> ( we've done a lot of different experiments thus far, have honed down on to using eInk as being the 'next most viable option'
[04:21:08] <jerkey> i wish i understood the difference between an eInk screen and a properly illuminated LCD
[04:22:02] <inflex> jerkey: eInk is passive, subtractive; it's using microscopic balls with black pigments in them
[04:22:22] <inflex> http://en.wikipedia.org/wiki/E_Ink
[04:22:41] <jerkey> i will think about that as I sleep. good night.
[05:51:20] <devilsadvocate> inflex: eInk is especially slow. It only really works for static text. It'd be especially irritating if you're trying to write on it.
[05:51:40] <devilsadvocate> inflex: in some ways it's similar to the etch-a-sketch screens
[05:52:44] <inflex> devilsadvocate: yes - not expecting it to be super fast; I actually have a few eInk devices, so certainly I've seen how painful they can be. Fortunately though when you're touch typing you don't tend to notice it so much.
[05:53:28] <inflex> The latest ones have about a 200ms refresh/update on them which is fairly acceptable
[05:54:47] <inflex> This isn't really going to be a general purpose machine. It's single purpose is to be a rudimentary text entry system with limited levels of editing.
[06:09:20] <clixxIO_> anybody seen this ?
http://jumptuck.com/2008/11/13/led-menorah-powered-by-avr-tiny13/
[06:10:02] <clixxIO_> I'm trying to get my attiny's to sleep, stumbled upon that, quite interesting
[06:54:23] <abcminiuser> http://i.imgur.com/rMDgk94.gif
[09:25:59] <pingec> What kind of error detection could I implement on a serial connection?
[09:41:06] <aep> i wonder if i can use the arduino bootloader for regular hex files?
[09:41:15] <aep> i'm too lazy to write my own thingy
[09:41:33] <aep> and i just can't get my ISP working
[09:52:19] <OndraSter_> pingec, any... there already are hardware ones like parity etc
[09:52:54] <OndraSter_> feel free to add CRC after each block ;)
[09:56:30] <megal0maniac_afk> aep: You can. It's a decent bootloader
[09:56:51] <aep> got any links?
[09:57:03] <aep> all i find is how to use it with their IDE
[09:57:48] <pingec> OndraSter_ every few thousand of transfered lines
[09:57:53] <pingec> I get a way off number
[09:58:25] <pingec> Not sure if its a serial connection error or a bug in my code
[10:04:18] <megal0maniac_afk> aep:
https://code.google.com/p/optiboot/
[10:05:30] <megal0maniac_afk> aep: Step 11
http://kalium-projects.blogspot.com/2013/05/burning-arduino-bootloader-optiboot.html
[10:05:41] <aep> nice, thanks!
[10:06:09] <megal0maniac_afk> Oh. Nevermind, ignore that second message
[10:06:36] <aep> oh its flashing the thing, not a hex file using it
[10:06:40] <aep> that'd be the question
[10:07:33] <aep> i'll just use the omlex board for now until my new ISP arrives
[10:08:23] <aep> can anyone tell me whats wrong with this ricidulously simple code:
http://npaste.de/p/flOo ? Instead of setting the pin and keeping it set, it is pulsating at visibly low frequency. like 300Hz
[10:09:18] <aep> maybe the chip resets? but i didnt write anything that would make it do that
[10:24:12] <aep> was a fricking watchdog. how would i know the crap is on by default ....
[10:24:37] <aep> the datasheet doesnt say that
[10:39:04] <twnqx> so i have a 46" display with a broken mainboard
[10:39:09] <twnqx> and a rapberry by
[10:39:11] <twnqx> pi
[10:39:20] <twnqx> makes me wonder if the lvds connectors are compatible...
[10:40:30] <twnqx> or can be made compatible :P
[10:52:48] <aep> twnqx: cubieboard has an lvds breakout board and an actual gpu that does it
[10:53:16] <twnqx> pi has it too
[10:53:21] <twnqx> but the connector doesn't match
[10:53:27] <aep> i heard it doesn't work so well. but no idea
[10:55:43] <carabia> so you guys know a thing or two bout lifepo/a123?
[10:56:33] <carabia> i'm curious about the needed low voltage protection
[10:57:25] <carabia> thinking of replacong my lipo usb bat with lifepos
[10:57:34] <carabia> batt*
[10:58:25] <carabia> fuck touchscreens and fuck em hard...
[11:03:43] <megal0maniac_afk> theBear: You around?
[11:06:17] <theBear> does the pope wear half a beanie ?
[11:07:20] <theBear> and is it just my paranoid nature, or is he the only christian on the entire planet who DOES wear half a beanie, and if so, what's up with that ?
[11:07:48] <theBear> i'll give you some thinking time, but the countdown clock IS ticking
[11:07:54] * theBear fades in the thinking music
[11:10:57] <carabia> yeah neil young
[11:12:37] <carabia> i myself would go ace of base. such brilliance totally forgotten. people only remember abba and mby europe :(
[11:13:38] <carabia> i wonder if any component dealer sells lifepos...
[11:14:09] <carabia> id need some stuff also and im really n8t in the mood for paying double postages
[11:14:15] <Chocobo> Hi all... I am trying to remember the name of a programmer that could target multiple microcontrollers (AVR being one them). Does anyone know of such a thing?
[11:14:24] <Chocobo> I believe it was open source.
[11:14:51] <carabia> dasa
[11:14:58] <carabia> :DDDDDDDDD
[11:15:30] <carabia> lolol. just bitbang. its how we heavy hitters do shit
[12:19:50] <carabia> baw
[12:20:45] <carabia> no-one knows of a store selling lifepo-cells? =o one that would possibly sell components aswell?
[12:21:08] <Casper> not many place sell them
[12:21:20] <Casper> the manufacturers don't produce enought of them, to keep the price high
[12:24:09] <carabia> i know i can get single cells from hobbyking
[12:24:17] <carabia> even single cells*
[12:24:42] <carabia> but it's kind of stupid cause the shipping costs are high and i also need other stuff :[
[13:05:00] <shorted_neuron> carabia: i get lifepo4 from all-battery.com . They seem to be of good quality. I have some that sit out in the weather and do low current stuff, they have been going great for about two years. I also have a couple sets in high current applications and they have done well too
[13:05:16] <shorted_neuron> i also like that i can order many sizes of cells, and most have the option for solder tabs.
[13:39:53] <megal0maniac_afk> theBear: Good to know you're still around ;) You've been quiet
[13:41:28] <OndraSter> not sure if I will be around though - I always wanted to do hardware. Instead I worked as an on-site support for a world-wide company; server guy (Windows + Linux); networking guy (Windows + Linux + a li'le of Cisco) and of course PHP... but so far no hardware (in some company)
[13:43:36] <vectory> OndraSter: wc
[13:43:45] <OndraSter> wc?
[13:48:01] <theBear> i was err, sans internets, as a douche might say, a couple times over the last month or so, and ya know, trying to moderatetalking too much before i actually do ANYTHING say, this decade, avr wise :)
[13:49:09] <theBear> but i'm just putting the finishing touches on my new parport programmey interface, but pretty sure it's still incapable of isp so it's kinda irrelevant to my avr activity
[13:49:34] <theBear> i did touch a few end-of-tubes with a handful of various ancient models shiny and new
[13:50:06] <theBear> does that count ? i also know where both my programmers and my serial-rif-a-majig
[17:14:04] <Konky> I use Code::blocks and the symbol browser does not list declartions like PD0 PINA DDR* etc. The code compiles fine, just the code completion does not seem to load the declartions. anyone knows that problem/bug and how to solve it ?
[17:14:49] <Ni1njaneer> Are you including the appropriate AVR headers files like io.h and such, and ensuring the device directive is defined?
[17:15:16] <Konky> yes, io.h is included. also no compiler/precompiler problems
[17:18:11] <Konky> So my problem is not a common issue ?
[17:18:49] <Ni1njaneer> Is the processor type #defined? io.h and similar will not include anything useful if it's not.
[17:19:03] <Konky> aaah maybe just in the makefile
[17:19:05] <Konky> i will chec kthat
[18:05:25] <clixxIO> hello, has anyone made a car ecu with an AVR ?
[18:06:15] <clixxIO> anyway, my question is an AVR going to be fast enough to read all timing pulses?
[18:06:53] <Ni1njaneer> Not if the car is blue.
[18:07:26] <Ni1njaneer> Your question is honestly too general. You need to provide specific parameters in order for the quesion to have relevance.
[18:07:35] <clixxIO> there are 24 pulses per rpm, so 24 x 5000 = 120,000 pulses per second
[18:07:51] <clixxIO> sorry, I had to calculate it out
[18:08:27] <Ni1njaneer> Depends on the specific criteria. How do you need to measure them? What kind of jitter is acceptable? How many channels are you reading? Do you need to read all channels at once or can you TDM, etc?
[18:08:33] <clixxIO> so every pulse is 0.000008333
[18:08:34] <Ni1njaneer> Have you done stuff with AVR's yet?
[18:09:01] <clixxIO> basic things, but I'm a professional programmer
[18:09:18] <Ni1njaneer> Start simple and work your way up from there.
[18:09:34] <Ni1njaneer> Embedded and hardware is a totally different ballgame :)
[18:09:56] <clixxIO> well I got this far :
https://plus.google.com/109366813998920635083/posts/DNoCzU3y6qs
[18:10:00] <Ni1njaneer> Professional software experience helps, but you need to thoroughly understand the strengths and limitations of the target you are trying to use.
[18:10:55] <clixxIO> one wheel has 24 teeth, and the other two teeth
[18:11:03] <Casper> clixxIO: you have 20MHzm ad 120k pulses, does that leave enought cycles per instruction?
[18:11:04] <Ni1njaneer> You also need to figure out the overarching parameters of what you are attempting to do in the grand scheme of the application. That will ultimately determine the criteria of measurement the underlying hardware must be capable of.
[18:11:28] <clixxIO> Casper: yes
[18:11:40] <clixxIO> casper: that's my question
[18:12:13] <Ni1njaneer> That's 166 cycles/sec at a raw level. What kind of measurements do you need to make, what calculations do you need to perform, and what/where are you shuffling that information to?
[18:12:32] <Casper> I don't know what you need to do between each pulses, so I can't say
[18:12:47] <Ni1njaneer> And how accurately do you need to measure the pulses?
[18:12:51] <clixxIO> so every 6 pulses, I need to lower a logic pin, to cause a spark plug to fire
[18:13:04] <Ni1njaneer> How much jitter can you tolerate?
[18:13:23] <clixxIO> not sure
[18:13:32] <Ni1njaneer> Sounds like a fun project. Just start small and move up from there. :)
[18:13:36] <Casper> I'ld say that the avr is fast enought
[18:13:45] <Casper> I've seen it done on model engine
[18:14:22] <clixxIO> It's working now, the only problem is that it's obviously running very slow
[18:14:36] <clixxIO> detecting the pulses is running
[18:14:44] <clixxIO> but via an analog port
[18:15:24] <Casper> you want a digital pin with an interrupt
[18:15:35] <clixxIO> and I'm only getting 1v pulses which aren't great enough to flip a digital pin
[18:16:03] <clixxIO> so I will probably need to add a transistor
[18:16:47] <Casper> or some other kind of buffer
[18:17:19] <clixxIO> oh ok, what's the point of those in this context?
[18:17:45] <clixxIO> (sorry - I have knowledge gaps here and there)
[18:18:40] <Casper> the buffer would act as a voltage translator
[18:19:22] <clixxIO> oh ok, like a 74HC125?
[18:19:33] <clixxIO> for example
[18:19:43] <Casper> I don't know if that one would work (need to check what it is actually)
[18:20:03] <clixxIO> no problem, I can research it further
[18:20:40] <hackvana> clixxIO: Hi
[18:20:41] <Ni1njaneer> Or use a high-speed comparator.
[18:21:02] <Ni1njaneer> That will provide a nice clean and deterministic digital input that you can set to any threshold.
[18:21:03] <clixxIO> hi hackvana, good morning
[18:21:21] <hackvana> Do you know what a PLL is?
[18:21:41] <inflex> phase locked loop
[18:21:42] <clixxIO> not really
[18:21:48] <inflex> wikipedia it :)
[18:22:04] <Casper> clixxIO: the input voltage is inadequate, but basically that yeah
[18:22:51] <Casper> you probably want hysteresis on the input, so a slightly varying signal don't cause havok
[18:23:12] <Ni1njaneer> Casper: High-speed comparator with hysterisis would work fine :)
[18:24:44] <clixxIO> I've checked - there is some varience in the signal level, but I smoothed it ok in software
[18:24:55] <Casper> let's say 0-1V signal, and a comparator at 0.5V... when the signal is at 0.5V exactly, you would get tons of garbage on the output, because any noise would make it like 0.5001 and 0.4999V adding histeresis would make the translation level be like 0.3V and 0.6V, so to get a 1 you need the voltage to go over 0.6V, and will "latch" to that value until the input drop bellow 0.3V and will "latch" again there until the input go over the 0.6V
[18:25:20] <Casper> usually the 2 levels are 1/3 and 2/3 of the signal
[18:25:25] <clixxIO> yeah, I already did that in software
[18:25:46] <clixxIO> but need to move off the analog ports and onto the digital ports
[18:26:05] <clixxIO> so yes, looks like I need that
[18:27:06] <jacekowski> shmitt trigger
[18:27:10] <jacekowski> schmitt
[18:27:16] <jacekowski> something like that
[18:27:20] <Casper> yup
[18:28:08] <Casper> you know... I wonder when they will start to make drive by wire for brakes and the power steering...
[18:28:20] <Casper> do you imagine the havok it will create?
[18:28:48] <jacekowski> not really
[18:28:50] <twnqx> power steering i think already has it
[18:28:53] <clixxIO> I've heard prius's are easily hackable
[18:28:57] <jacekowski> drive by wire throttle doesn't fail
[18:29:05] <twnqx> lol jacekowski
[18:29:11] <twnqx> some deas toyota drivers beg to differ
[18:29:15] <twnqx> dead*
[18:29:33] <twnqx> http://www.edn.com/design/automotive/4423428/Toyota-s-killer-firmware--Bad-design-and-its-consequences
[18:29:39] <twnqx> here, have some reading
[18:29:54] <Casper> twnqx: actually, it was proven that the system was fine
[18:29:57] <twnqx> no
[18:30:05] <twnqx> in fact it was proven that the system failed
[18:30:10] <twnqx> with no working failsafe
[18:30:33] <Casper> they, however, found out many issues unrelated with the system per se, like inapropriate floormat...
[18:30:37] <Casper> twnqx: source?
[18:30:42] <twnqx> the link i just posted
[18:30:54] <jacekowski> twnqx: that's loads of BS
[18:31:07] <jacekowski> twnqx: i did not find a single article saying that they found the bug and fixed it
[18:31:11] <Casper> let me pay my car insurance before I read and comment, but I suspect it's bs
[18:31:34] <twnqx> um, a court approved analyst working with NASA produced BS for determining the cause
[18:31:37] <jacekowski> twnqx: but instead, i found articles saying that all it was a throttle ending up being stuck under the carpet/mat
[18:31:45] <twnqx> yes, that too
[18:32:04] <twnqx> you know, they are quoting the court documents
[18:32:10] <twnqx> can only be BS, of course
[18:32:22] <clixxIO> there are actually multiple springs in the throttle body as failsafes
[18:32:32] <twnqx> fuck, i have my own car's engine controller in front of me
[18:32:37] <twnqx> no lockstep cpu
[18:33:25] <clixxIO> in the TPS (throttle-position-sensor) there's a return spring
[18:33:57] <clixxIO> there's also a return spring on the throttle-body valve
[18:34:06] <twnqx> ... so?
[18:34:30] <twnqx> how does that prevent faulty software from accelerating?
[18:34:38] <Casper> some driver reported that they got the issue WITH THE TRANSMISSION ON NEUTRAL and also some said that the KEY WAS OFF
[18:34:47] <twnqx> yeah, stupid
[18:35:01] <Casper> twnqx: if the cpu lock, it won't fire
[18:35:08] <twnqx> noone said lock
[18:35:10] <clixxIO> I have no sympathy for stupid computer users :-)
[18:35:18] <twnqx> neither have i
[18:35:24] <twnqx> but i have seen so much crap programming
[18:35:30] <clixxIO> probably an id10t error
[18:35:36] <twnqx> that i am not happy having to rely on computers
[18:35:46] <Casper> so the insurances paid.. now time to read your link
[18:35:46] <jacekowski> sudden unintended acceleration is quite common in other cars, all with automatic gearboxes
[18:35:58] <jacekowski> where some moron can't tell the accelerator from the brake
[18:36:08] <clixxIO> right
[18:36:13] <twnqx> why don't you just read the article first, then comment
[18:36:25] <twnqx> anyway, there was at least one more case
[18:37:00] <clixxIO> I'm not a fan of some automatic gearboxes
[18:37:03] <twnqx> with dynamic power steering (speed dependent amplification for easier parking while more resistence on higher speed)
[18:37:20] <twnqx> you know, BMW managed an integer overflow
[18:37:32] <twnqx> guy i know totaled his brnad new 7 series thanks to that
[18:37:56] <twnqx> when it suddenly went into parkiong aplification at > 256km/h on the highway
[18:38:02] <aep> bah, still can't figure out how lufa works. Endpoint_IsINReady is never true
[18:38:25] <aep> why do none of the examples work out of the box :/
[18:38:45] <jacekowski> twnqx: i've read the article and it's load of BS, first they say that it possibly could be hardware but it's not the case here, then they say that code quality was poor, then they say that real stack usage is higher than toyota predicted (it's a fuck up by toyota) but as much as 94% is a lot higher than 41% it's still not 100% that would be required to cause stack overflow,
[18:39:15] <jacekowski> twnqx: there is nothing saying "we found the bug"
[18:40:02] <twnqx> yeah, because it's trivial to have dynamic systems with external events and inputs in static code analysis, fault free
[18:40:21] <twnqx> if the bug was easy to trigger you would not have only a few
[18:40:31] <jacekowski> twnqx: no, i develop system like that every day
[18:41:00] <Casper> twnqx: the article is total bs
[18:41:18] <jacekowski> twnqx: but if things go wrong, after spending a lot of time looking into what i have, witness statements, code, all logged data i can go back and say "i found the bug, it's not going to happen again"
[18:41:30] <twnqx> yeah
[18:41:31] <twnqx> sure
[18:41:39] <twnqx> because you can always predict a single bit flipping
[18:41:45] <twnqx> in your rtos
[18:41:51] <Casper> they talk about bad throttle sensor, even if it was the case... THE SENSOR IS REDUNDANT! a dual fault is basically impossible, and would be detected even before such thing happend and would cause a code to trigger and be stored
[18:41:52] <twnqx> and then you say "that won't happen again"
[18:42:15] <twnqx> they talk about rtos processes with no monitoring
[18:42:15] <Casper> unresonable quality do not mean bugged
[18:42:30] <twnqx> and the possibility that a single-bit error can shut down a task
[18:42:34] <twnqx> which won't be recognized
[18:42:53] <Casper> they claim bugs that can cause UA, but do not talk about anything in particular... ok, it may be there, but back it up!
[18:43:04] <jacekowski> twnqx: it shuts down a task and engine shuts down
[18:43:16] <Casper> code quality metric is a total BS metric, should have been left out of the article
[18:43:17] <twnqx> that would depend on the desigtn
[18:43:23] <jacekowski> twnqx: they didn't say it doesn't have monitoring
[18:43:41] <twnqx> hey, the throttle reading task just got shut down, acceleration is staying on last level whatever you do
[18:43:47] <Casper> faulty failsafe, but don't give any clue of what's wrong
[18:43:50] <jacekowski> Casper: typical throttle sensor has analogue sensor (potentometer), and a switch saying that is over 10% or something like that
[18:43:56] <twnqx> no
[18:44:01] <twnqx> mine just has two pots
[18:44:05] <twnqx> and that's it
[18:44:20] <Casper> jacekowski: dual hall sensor is what I think toyota use
[18:44:25] <jacekowski> Casper: if ECU detects that you get 20% from the pot and over 10% switch isn't made then it knows something went wrong and can go into some sort of emergency mode
[18:44:53] <twnqx> jacekowski: you should hire qith audi, they could use your input
[18:45:05] <twnqx> there is no switch
[18:45:12] <twnqx> just two analog pots.
[18:45:13] <Casper> but look at the report of UA for toyota and the other brands
[18:45:21] <jacekowski> twnqx: depends on the implementation
[18:45:24] <Casper> toyota is bellow all the other brands
[18:45:28] <jacekowski> twnqx: some cars use analogue + switch
[18:45:33] <jacekowski> twnqx: that's what my car uses
[18:45:48] <Casper> meaning that if such bug was existant, it would have made that statistic way higher
[18:45:54] <jacekowski> Casper: on top of that on my car (and few other cars), engine will refuse to rev above ~1500RPM when brake is applied
[18:46:15] <clixxIO> how crap
[18:46:18] <twnqx> i haven't tried
[18:46:26] <twnqx> but how do you powerslide with that? :>
[18:46:32] <clixxIO> i couldn't live with a car like that
[18:46:49] <clixxIO> how can it double-clutch?
[18:47:12] <jacekowski> clixxIO: double clutching is a waste of time on synchronised gearboxes
[18:47:33] <twnqx> huh
[18:47:43] <jacekowski> as in, all modern gearboxes
[18:48:00] <twnqx> double clutching is used do have a second gear presynced and switch faster than single clutching, from my understanding
[18:48:01] <clixxIO> nah, I meant holding the brakes on going into a corner whilst holding rpm > 4000 for corner exit
[18:48:21] <jacekowski> twnqx: double clutching was required on old non synchronised gearboxes
[18:48:35] <aep> abcminiuser: hey. i'm a step further trying to port the AudioInput.c example to an at90usb162. the ISR works fine but Endpoint_IsINReady never returns true. any idea there?
[18:49:07] <aep> any my linux host says: retire_capture_urb: 4993 callbacks suppresse
[18:49:10] <twnqx> jacekowski: and that is the reason every highend car maker praises double clutches as the state-of-the-art gearbox despite the higher weight?
[18:49:13] <clixxIO> I drove a new corolla with their new auto gearbox - they really suck
[18:49:16] <hackvana> clixxIO: A PLL is a useful thingy when you are dealing with an external periodic signal, for example, pulses from the distributor
[18:49:32] <jacekowski> twnqx: double clutch gearboxes are something completly different
[18:49:38] <hackvana> It can be in hardware (for example, 4046 chip), or software, or hardware/software.
[18:49:39] <jacekowski> twnqx: those are automatic gearboxes
[18:49:46] <jacekowski> twnqx: you don't have a clutch pedal there
[18:49:52] <twnqx> i know
[18:49:54] <jacekowski> twnqx: and they work on completly different principle
[18:50:05] <twnqx> they work on having the next gear presynced
[18:50:17] <hackvana> Basically, you generate a periodic signal, and use the difference between your signal and the external signal to tweak the period of your signal.
[18:50:19] <twnqx> so you (they) can open one clutch while closing the other
[18:50:31] <jacekowski> twnqx: double clutching is a completly different thing, done on a manual gearbox
[18:50:35] <twnqx> oh
[18:50:42] <twnqx> never even heard of that
[18:50:42] <jacekowski> twnqx: and it's only done when shifting gears down
[18:50:44] <clixxIO> gears are not much use to me at the moment, till I get some spark happening
[18:50:49] <hackvana> The reason you might be interested in this is that if you find the distributor signal is too late, PLL will let you "lead" that distributor signal
[18:50:53] <jacekowski> twnqx:
https://en.wikipedia.org/wiki/Double_clutch
[18:51:28] <hackvana> So you can generate the plug pulse before the distributor pulse arrives
[18:51:38] <hackvana> Think of it as programmable advance/retard
[18:51:51] <twnqx> ok... never heard of that. only knew the automatic ones which are called double-clutch...
[18:52:39] <jacekowski> twnqx: what you do is, change to neutral, release the clutch, rev the engine up so gearbox/engine speed becomes synchronised with "road" speed for your target gear, clutch again shift into your target gear, release clutch
[18:53:17] <twnqx> why would you release the clutch in between?
[18:53:25] <jacekowski> twnqx: modern gearboxes have something called synchronisers, which are small clutches that will speed the gearbox up or down as you move gear lever
[18:53:27] <lclark> twnqx: I believe auto trans use multiple clutches to smooth gear changes.
[18:53:41] <jacekowski> twnqx: because if you don't release the clutch, gearbox will stop
[18:53:52] <clixxIO> hackvana: I will try again later tonight when I get home
[18:54:02] <twnqx> i once had a broken gearbox in a manual transmission car where i had to adjust rpm, but never did release the clutch in between :X
[18:54:32] <jacekowski> twnqx: when you are in neutral, and with no "power" supplied to gearbox everything will slow down and stop
[18:54:49] <twnqx> yeah but it takes fractions of a second to adjust rpm :S
[18:55:05] <jacekowski> twnqx: that still only works on synchronised gearboxes
[18:55:25] <jacekowski> twnqx: asmuch as it was probably a badly worn synchronisers
[18:55:30] <twnqx> adjusting rpm? that's next to instant with the clutch oulled
[18:55:39] <twnqx> yes, it was of course
[18:55:49] <twnqx> had to have the whole gearbox replaced
[18:55:51] <lclark> jacekowski: car moving, clutch out, in neutral; the clutch will be spinning at engine speed, the trans will be spinning with the drivetrain.
[18:55:52] <jacekowski> twnqx: it wouldn't work on non synchronised gearbox
[18:56:18] <twnqx> i technically don't see why...
[18:56:30] <jacekowski> lclark: half of the gearbox will be spinning at the drivetrain speed
[18:56:39] <jacekowski> lclark: other half will have no power input
[18:56:44] <twnqx> in neutral
[18:56:54] <jacekowski> lclark: and will slow down/stop
[18:56:54] <twnqx> but it won't slow down in half a second or so
[18:57:10] <twnqx> while my engine can go from idle to limiter and back in less than a second
[18:57:18] <twnqx> with no gear
[18:57:21] <jacekowski> twnqx: no, but when you shift down, it has to be spinning faster than it was spinning in higher gear
[18:57:35] <clixxIO> hackvana: I don't think I need PLL, because I just need to fire the spark plug every 6 pulses
[18:58:05] <twnqx> clixxIO: now that you mention it
[18:58:11] <hackvana> Be that as it may, it's a useful technique to keep in mind if you need an output signal which is related to the input signal, but not at the same time
[18:58:16] <twnqx> i think i saw some guy do that with pic
[18:58:24] <hackvana> Out of phase
[18:58:32] <clixxIO> hackvana: I mean one of the four COP's every six pulses
[18:58:43] <twnqx> clixxIO: whichi country are you from, out of curiosity
[18:58:51] <hackvana> PLLs can also be used for things like frequency multiplication
[18:58:52] <jacekowski> twnqx: shifting up is easy
[18:58:57] <clixxIO> australia
[18:59:05] <twnqx> no emission laws there?
[18:59:20] <clixxIO> apparently there are
[18:59:35] <clixxIO> but not strongly enforced
[18:59:37] <jacekowski> in australia they have no laws
[18:59:42] <jacekowski> they are all criminals over there
[18:59:49] <clixxIO> pretty much
[19:00:38] <clixxIO> the car has a cat convertor - that's enough
[19:00:52] <jacekowski> and doing back to the guy crashing BMW because of power steering integer overflow
[19:00:58] <jacekowski> going*
[19:01:02] <jacekowski> WTF???
[19:01:09] <twnqx> yeah well
[19:01:22] <jacekowski> power steering will not affect the ratio or anything like that
[19:01:26] <clixxIO> but my plan is to go a bit lean, maybe the cat-convertor wont work
[19:01:28] <twnqx> yes, it does
[19:01:31] <jacekowski> it will just make it easier/harder to turn the wheel
[19:01:35] <twnqx> not "just" power steering
[19:01:57] <jacekowski> actual relation of wheel angle to the steering wheel position is fixed and can not change
[19:02:01] <twnqx> but the modern unlinked electic ones do...
[19:02:09] <clixxIO> did the guy who crash the BMW mention the blonde in the passenger seat and what she was doing?
[19:02:23] <clixxIO> JaJa - integer overflow
[19:02:31] <clixxIO> for the insurance report...
[19:02:33] <twnqx> no, but that bmw gave him a new car to get hold of the wreck
[19:03:05] <twnqx> http://imageshack.com/a/img824/2338/modsih.jpg that engine controller runs any code you upload to it, btw :)
[19:03:23] <clixxIO> to my knowledge, bmw generally don't acknowledge vehicle faults
[19:03:47] <clixxIO> or if they do, suggest its time to upgrade to a newer/fixed model
[19:04:30] <jacekowski> twnqx: so even if something went wrong with power steering, all it would do is make it very easy to turn the wheel
[19:04:31] <clixxIO> twqnx: what type of controller is that?
[19:04:51] <twnqx> that's from an audi 3.2fsi
[19:04:59] <twnqx> tc1796 cpu
[19:05:15] <jacekowski> yeah, it's a typically a fairly standard CPU in those
[19:05:21] <jacekowski> car ECUs are nothing special
[19:05:31] <jacekowski> just little bit more rugged
[19:05:43] <jacekowski> built to work from -50C to +100C
[19:05:54] <jacekowski> with a lot of vibration
[19:06:07] <clixxIO> and water
[19:06:12] <abcminiuser> What did I miss?
[19:06:14] <jacekowski> but that's about it when compared to any other electronic devices
[19:06:20] <twnqx> i modded the thing to boot from CAN
[19:06:28] <jacekowski> clixxIO: well, they generally keep water away from it
[19:06:37] <twnqx> the sealed casing does
[19:07:09] <twnqx> and the fact that there's a sticker sealed hole in the casing tells me they made sure condensation won't be a problem either
[19:07:17] <clixxIO> not how I drive, water sometimes comes up to the windows
[19:07:29] <twnqx> it's still hermetically sealed
[19:07:39] <twnqx> heck, it's difficut to open of those up :P
[19:07:45] <jacekowski> twnqx: that ECU, i'm surprised it's not filled with that jelly like stuff
[19:07:54] <jacekowski> twnqx: they like to use it on this stuff
[19:09:12] <twnqx> i opened two of these, had to remove the BGA from one :P
[19:09:12] <twnqx> neither had such a filling
[19:09:12] <twnqx> thaat would have been an unpleasant surprise
[19:09:52] <Casper> they should just epoxy pot everything!
[19:10:14] <clixxIO> twnqx: is the software 'open' for those ecu's?
[19:10:27] <twnqx> jacekowski: know any better disassembler/software emulator for the tc1796? IDA fails on it pretty much due to the 16bit+16bit immediate register load before jump :X
[19:10:32] <twnqx> clixxIO: no
[19:10:54] <clixxIO> didn't think so
[19:11:12] <clixxIO> is it hacked/modded?
[19:11:13] <twnqx> i think i saw a youtube vid of someone building an ECU with a PIC
[19:11:31] <jacekowski> twnqx: nah, but i'm willing to bet that latest version of ida has improved cpu plugin
[19:11:32] <twnqx> this one? yeah well, modded to boot from CAN so i could read the flash
[19:11:44] <twnqx> which is amazingly not even read protected
[19:11:50] <jacekowski> http://74.124.198.224/~lance/index.html
[19:12:35] <Jan-> hihi :)
[19:12:56] <Epsilon-Auriga> lolo
[19:13:03] <jacekowski> petrol engine DIY ECU
[19:13:25] <jacekowski> basic ECU is quite simple
[19:13:37] <twnqx> yeah.. this one not so much
[19:13:42] <Jan-> if I'm writing normal C code that I want to upload to an arduino nano, what do I want? "gcc c executable project"?
[19:13:44] <jacekowski> engines run for ages with no ECUs at all
[19:14:01] <twnqx> i know, i had one of those too .)
[19:14:09] <jacekowski> well, mechanical ECU
[19:14:48] <Jan-> holy shit this is awesome, this is like writing AVR C code in visual studio!
[19:14:49] <jacekowski> but now you have modern diesel engines that can inject fuel 12 times during a cycle
[19:14:50] * Jan- waves her arms
[19:14:56] <Jan-> this rocks!
[19:15:02] <Epsilon-Auriga> Jan-: you using atmel studio?
[19:15:08] * Jan- *nodnodnod*
[19:15:16] <Jan-> last I used was avr studio 4
[19:15:17] <Epsilon-Auriga> then you ARE writing avr C code in visual studio.
[19:15:21] <twnqx> but this one works with 2 catalytic converters, 4 oxygen sensors, 2 cylinder banks with independent hall sensors, two-mode adjustable camshaft, ...
[19:15:31] <Jan-> Epsilon-Auriga: Oh.
[19:15:35] <Jan-> Well, still. Yeay.
[19:15:41] <Epsilon-Auriga> bleh.
[19:15:45] <Epsilon-Auriga> windows only IDE.
[19:16:31] <Epsilon-Auriga> give me a text editor and command line any day.
[19:16:33] <clixxIO> well I will do the fuel-injector control after I get the spark-plug control thing working
[19:16:44] <Jan-> why does it say "global.h no usch file or directory"
[19:16:55] <Epsilon-Auriga> because it can't find global.h
[19:19:05] <Jan-> you really are a wise guy, aren'tcha
[19:19:10] <Epsilon-Auriga> yup.
[19:19:25] <Epsilon-Auriga> but, it is a straightforward answer.
[19:19:38] <Epsilon-Auriga> for some reason your compiler can not find global.h
[19:20:17] <Jan-> the phrase "you're a wise guy" is usually a hint to siddown and shut up
[19:20:38] <Epsilon-Auriga> I am sitting and haven't said a word in an hour....but I type well.
[19:21:53] <Jan-> biggest problem I now have is all my old code in AVR studio 4.
[19:22:03] <Jan-> God knows how I'm gonna port that over, I guess copy and paste is one approach.
[19:22:11] <Tom_itx> to what?
[19:22:15] <Epsilon-Auriga> does not the new atmel studio do import of old projects?
[19:22:19] <Tom_itx> yes
[19:22:20] <clixxIO> another related question, why do ignition-coils fail? (otherwise I wouldn't be messing with avr's)
[19:22:28] <Tom_itx> because
[19:23:04] <Jan-> hmm
[19:23:14] <Jan-> I did have a feeling that v6 would be overkill.
[19:23:18] <hackvana> Dielectric breakdown maybe
[19:23:22] <Jan-> Now it's forcing me to set options for things that don't apply, like debuggers.
[19:23:25] <clixxIO> I know, but my spark plugs got sooted up
[19:23:29] <Tom_itx> anything beyond an editor and avrdude is overkill
[19:23:52] <Tom_itx> deboogers
[19:24:08] <Jan-> bleargh
[19:24:14] <Jan-> still, I quite like visual studio
[19:24:16] <Jan-> it's super-helpful
[19:24:25] <Tom_itx> i don't see how in your case
[19:24:59] <Tom_itx> and it pig ass slow
[19:25:57] <Jan-> if I've learned anything about this stuff, it is that no matter what tool I choose, someone will tell me to use something else.
[19:26:39] <Epsilon-Auriga> to each their own...use what works best for you.
[19:26:51] <Tom_itx> i don't care what you use i just think studio 6 is overkill for compiling code for a tiny little chip
[19:26:54] <Epsilon-Auriga> I just can't help you with atmel studio as it does not run on my computer.
[19:27:28] <Epsilon-Auriga> I do have a computer with windows on it and atmel studio installed but it takes 5 minutes just to start.
[19:27:39] <Tom_itx> exactly.
[19:28:21] <clixxIO> thanks everybody for your suggestions. I will go away and implement what I have learned here today
[19:28:43] <carabia> D:
[19:29:09] <Jan-> if you want evidence that I'm some sort of real-ale, low-level afficionado, know that I come here fresh from a bruising encounter with arduino.
[19:29:19] <Jan-> I couldn't make it sample its ADC at more than about 280hz, which seemed to suck a bit.
[19:29:24] <carabia> i hope he won't get a crank shaft shot up to his head
[19:29:39] <Epsilon-Auriga> Jan-: that's the speedy(not) ardweeny libs for you.
[19:30:42] <Tom_itx> if you need absolute speed do it in asembler
[19:30:46] <lclark> jacekowski: got distracted; following up; neutrual means the input shaft and output shafts are disconnected, but they are both spinning, at least in the AX-15 and whatever it is Honda used in their civics. The shifter locks the synchros on the spinning shafts together.
[19:30:49] <Jan-> screw THAT noise.
[19:31:00] <Jan-> honestly writing AVR C feels like assembler most of the time anyway
[19:31:15] <carabia> this is #electronics all over again and then... "is it okay if i take my rosin core (tm)(r)(c) solder now and my new some brand sd:D:S:SDa solder iron and ... guys... help me out... guyyys"
[19:32:08] <Tom_itx> carabia are you comparing avr to electronics now?
[19:37:24] <Jan-> oohhkay.
[19:37:35] <Jan-> I have some "blinky LED" code here that I think is probably correct and compiles.
[19:37:54] <Jan-> and yup there's helloworld.hex
[19:38:14] <Jan-> I am told that there are blackmagic behind-the-scenes ways to upload this to my lil arduino board using its USB/serial capabilities.
[19:38:36] <Jan-> Any suggestions? Apparently I need avrdude.
[19:38:48] <carabia> it's called a bootloader
[19:38:59] <carabia> which you totally don't need
[19:39:29] * PoppaVic gets the popcorn...
[19:39:30] <Jan-> well, hang on
[19:39:42] <Jan-> the main reason I'm using this hardware is so people can do easy field updates via USB.
[19:39:57] <Jan-> So yeah, I could patch up the ISP programmer and do it that way (at least, I assume I could, AVR studio 4 could).
[19:40:00] <Jan-> But I'd rather not.
[19:40:44] <Jan-> I found a tool called "xloader" which promises to do this.
[19:43:01] <Tom_itx> lies
[19:43:03] <Tom_itx> all lies
[19:43:45] <Jan-> ah.
[19:43:48] <Jan-> any suggestions?
[19:43:52] <Epsilon-Auriga> never heard of xloader but avrdude can upload through the arduino bootloader.
[20:05:39] <Jan-> okay, avrdude responds stk500_getsync(): not in sync: resp=0x00
[20:05:50] <Jan-> I assume it doesn't like "-P com3" or something
[20:17:18] <Jan-> Hm no -P com3 is correct.
[21:20:01] <Jan-> hey guys
[21:20:09] <Jan-> this should be an LED blinker, but isn't
http://pastebin.com/UdD6JZwL
[21:20:18] <Jan-> LED on portb (it's an arduino board) stays off.
[21:20:21] <Jan-> Any pointers?
[21:23:01] <tzanger> Jan-: instead of relying on the port value to change, have a toggle bit that you xor with 1 and if toggle is zero, clear portb, otherwise set it all ones
[21:23:23] <tzanger> I don't know fi that's specifically your problem but it's a potential gotcha
[21:23:27] <Jan-> okay.
[21:23:34] <Jan-> you suspect there may be an issue reading portb?
[21:23:44] <tzanger> depending on how things are wired there's potential
[21:25:04] <Jan-> hmm still no joy
[21:25:12] <Jan-> let me start with the LED off and set it on every time in the ISR
[21:25:19] <Jan-> that'll prove if it is *ever* being run
[21:25:49] <Jan-> ...no, it isn't
[21:25:53] <tzanger> beyond this I'd have to bust out the datasheet and see what you're doing
[21:26:01] <Jan-> is there any fuse stuff that could affect this
[21:26:23] <Jan-> to be honest that's what I did, but it didn't work. So my current code is basically copypasta'd from a website.
[21:26:28] <tzanger> I see you setting TCCR1B/MSK1 by ORing in values but you don't set them explicitly first
[21:26:42] <tzanger> never trust the reset values
[21:26:47] <Jan-> okay, let's see
[21:27:03] <Jan-> that was recommended technique, and I guess it makes sense to avoid stomping on things
[21:27:04] <tzanger> they may be right 99% of the time but that one time'll fuck you and you'll be so used to trusting them you'll never see it. not that I've ever been there before :-)
[21:27:24] <tzanger> yes it makes absolute sense to do it that way... once you have explicitly set the value somewhere
[21:27:33] <Jan-> I just took the |s out
[21:27:40] <Jan-> oh no wait I can't do that
[21:27:51] <Jan-> last one has to be an |
[21:28:03] <Jan-> but still no joy
[21:31:21] <Tom_itx> http://tom-itx.dyndns.org:81/~webpage/how_to/atmega168/mega168_led_blink_int_index.php
[21:31:53] <Jan-> now see tom, when I used your code on my 168 with your programmer, it workedfirsttime :)
[21:32:25] <Jan-> that said I don't understand why my code is not working, and I'd like to
[21:34:40] <Tom_itx> http://tom-itx.dyndns.org:81/~webpage/abcminiuser/articles/avr_timers_index.php
[21:34:40] <Tom_itx> http://tom-itx.dyndns.org:81/~webpage/abcminiuser/articles/avr_interrupts_index.php
[21:35:16] <Tom_itx> read those
[21:35:17] <Jan-> oh hm your fuse values are different
[21:35:40] <Jan-> oh hm
[21:35:48] <Tom_itx> they should be default factory settings
[21:35:59] <Jan-> well your code fails too so something wonky is going on
[21:36:12] <Jan-> avrdude reads lfuse, hfuse and efuse as 0
[21:36:38] <tzanger> that's not normla efuse
[21:37:25] <Jan-> to be fair it does say "avrdude: safemode: lfuse reads as 0"
[21:37:31] <Jan-> I'm not sure what safemode means
[21:37:50] <Tom_itx> avrdude -c usbtiny -p m168 -U lfuse:r:con:r -U hfuse:r:con:r
[21:37:56] <Tom_itx> change the programmer etc to suit
[21:38:44] <Tom_itx> http://tom-itx.dyndns.org:81/~webpage/how_to/atmega168/using_avrdude_index.php
[21:39:23] <Jan-> OK I think we have a blinkenlight
[21:39:38] <Jan-> I can't see it but the person who can says that he has to wave the circuit board in the air to see it as a dotted line.
[21:39:40] <Jan-> But it is flashing.
[21:40:06] <Tom_itx> it is flashing too fast to see
[21:40:11] <Jan-> well sure.
[21:40:52] <Jan-> I guess unless we get clever there isn't any divider big enough to make it visible to humans.
[21:40:53] <tzanger> oh, well just set your CLKDIV higher or reconfigure your prescalers accordingly
[21:41:44] <tzanger> almost all of my designs have a 100ms timer tick that I peel off for I/O multiplexing. if I need something faster I'll go down to 10 or even 1ms but anything that needs to be quiker than that I try to design in a better way
[21:42:45] <Jan-> what worries me is that my old code still doesn't work right
[21:42:46] <Jan-> oh well
[21:42:50] <tzanger> my RF stuff uses a int-on-pin-change and a one-shot timer of ~32us to differentiate between 1s and 0s
[21:42:51] <Jan-> perhaps I'll look at that tomorrow
[21:43:00] <Jan-> well.
[21:43:17] <Jan-> one problem I now have is that I have to rewrite a whole fricken library for the TM1638 display driver that was only available for arduino.
[21:43:27] * Jan- looks a bit grim
[21:43:29] <tzanger> that happens
[21:43:30] <tzanger> heh
[21:43:55] <Jan-> it's annoying because it has a shared I/O line, and if I screw up I could create contention and fry either of the two chips
[21:43:59] <tzanger> never used a TM1638 before
[21:44:07] <Jan-> cheapo dealextreme display baord
[21:44:23] <Jan-> probably I should get a shift register based one really, as the eventual project needs to be camera safe
[21:46:53] <Jan-> ok thanks guys I'm off to bed.
[22:45:16] <Ins1er> Русские есть?)
[22:48:27] <Ins1er> Ау, есть кто живой?
[22:48:54] * PoppaVic sighs
[23:13:44] * inflex stabs Auduino
[23:13:49] <inflex> Arduino even too
[23:22:26] <spec__> I'm trying to read the flash off a device. I issue: avrdude -c dragon_jtag -p m64 -Uflash:r:./3-digit.img:r -P usb -v
[23:22:30] <spec__> And it hangs
[23:23:00] <spec__> I can ^c out, but no outpup file is created
[23:23:46] <spec__> Does the parameter order matter?
[23:36:04] <spec__> nm, got it working
