Back
[01:09:28] <rue_more> umquant, I do
[01:09:37] <rue_more> typically you put a ...
[01:10:03] <rue_more> ohm -v 5 -i .020
[01:10:03] <rue_more> Wattage is: 0.100000
[01:10:03] <rue_more> Current is: 0.020000
[01:10:03] <rue_more> Voltage is: 5.000000
[01:10:03] <rue_more> Resistance is : 250.000000
[01:10:19] <rue_more> 250 ohm resistor across it and make sure you read between ...
[01:10:36] <rue_more> ohm -i .004 -r 250
[01:10:36] <rue_more> Wattage is: 0.004000
[01:10:36] <rue_more> Current is: 0.004000
[01:10:36] <rue_more> Voltage is: 1.000000
[01:10:36] <rue_more> Resistance is : 250.000000
[01:10:38] <rue_more> 1 to 5V
[01:13:50] <N1njaneer> That kind of depends on how much voltage is required in the current loop :)
[01:14:12] <N1njaneer> If you're dropping that much across the sense resistor.
[01:14:30] <N1njaneer> So it's more application-dependent.
[01:15:38] <rue_more> there is usually 24V or so available
[01:15:49] <N1njaneer> Usually you'll use a very small-value precision resistor that's 0.01 - 1 ohm, then you use a precision op-amp to multiply the voltage drop in to a range which is useful to read in your circuit. If you do it on the sink-end of the circuit you can just use a simple op-amp.
[01:16:40] <N1njaneer> Assuming you need to actually measure the current. If you just need to sense the presence, easier to just use an op-amp. Again, depends on the application. :)
[01:16:49] <N1njaneer> (which I'm not sure if he mentioned)
[01:17:21] <N1njaneer> Oh PLC stuff, I see that now in the backlog :)
[01:46:02] <Casper> is there any bootloader for a bus? I plan to network a few devices, and would like to be able to reflash them individually, but I think it's not possible
[01:46:13] <Casper> unless I program my own loader and all...
[01:58:29] <rue_more> N1njan33r, which gives you precision noise
[01:58:45] <rue_more> all industry equipment uses a 250 ohm resistor, 1%, as you mention
[02:28:06] <N1njaneer> rue_more: Depends on the application. But yes for the PLC stuff the 250 ohm resistor makes sense.
[02:29:05] <N1njaneer> If you are signaling with it vs say reading current in forming a constant-current driver.
[02:30:17] <N1njaneer> Casper: I'd just write the bootloader - they're not that difficult.
[02:31:07] <Casper> using 9n1 can also be usefull as the protocol
[02:31:20] <N1njaneer> Casper: Probably would need to customize any existing bootloader somewhat to satisfy your requirements.
[02:31:25] <Casper> use the 9th bit as a "slave select"
[02:31:36] <N1njaneer> What kind of a bus, though?
[02:32:18] <Casper> not sure yet
[02:33:57] <N1njaneer> RS485 is nice and very flexible
[02:34:38] <N1njaneer> Good topology flexibility, too. High-speed capable and from 32-256 devices possible with most drivers
[02:35:08] <N1njaneer> And relatively easy to do auto-identification of devices with unique serials
[02:36:58] <Casper> that's the one I was actualy thinking about
[02:37:24] <N1njaneer> It's extremely versatile.
[02:37:45] <N1njaneer> And only needs the TX, RX UART pins and a direction pin.
[02:38:10] <N1njaneer> And a biasing network somewhere on the bus for most reliable operation.
[02:46:21] <Casper> will check that... but I think it will ends up with nothing finally :D
[06:01:05] <Jartza> d'oh
[06:01:12] <Jartza> my modem ISR just shrinks
[06:01:17] <Jartza> now it's 12 lines of C
[06:01:30] <Jartza> (and two lines are just "}")
[06:38:43] <Kev> Jartza, it's just a "dem" if you only receive data :p
[06:55:57] <Jartza> true :)
[07:10:21] <Jartza> might be that it's so small as it's just "dem" :)
[12:40:05] <Bird|otherbox> so, how does LUFA's default control request handling work? or am I stuck having to implement all the control requests myself?
[13:26:38] <superware> I'm interfacing an ATmega328p with
http://www.usdigital.com/assets/general/LS7366R.pdf via SPI, but I still want to keep the ISP functionality of the atmega, any ideas?
[13:26:58] <Tom_itx> possibly add resistors
[13:27:03] <Tom_itx> really though... good luck
[13:28:11] <Thrashbarg> superware: A high to low transition at the SS/ (Slave Select) input
[13:28:11] <Thrashbarg> selects the LS7366R for serial bi-directional data transfer; a
[13:28:11] <Thrashbarg> low to high transition disables serial data transfer and brings
[13:28:11] <Thrashbarg> the MISO output to high impedance state
[13:28:13] <Thrashbarg> oops...
[13:29:01] <superware> can I connect SS/ to the atmega RESET/?
[13:29:09] <Thrashbarg> I figure what you need to do is put a pullup resistor on that pin, so when you're programming, the SS pin is high and disables the outputs
[13:29:41] <Thrashbarg> ~RESET is the opposite polarity to ~SS, when it's programming, ~RESET is low, and you need ~SS to be high
[13:30:19] <superware> yeah, forget about SS/ and RESET/
[13:31:22] <Thrashbarg> well if you put a resistor between ~SS and V+ and connect ~SS to a pin on the ATMega. Set that pin to 0 when running
[13:32:05] <superware> which resistor? :|
[13:32:13] <Thrashbarg> 1k ohm will do it
[13:32:50] <superware> yeah, thanks!
[13:34:00] <superware> Thrashbarg: should I use resistors between MOSI, MISO and SCK of both chips?
[13:34:14] <superware> in series..
[13:40:19] <superware> I mean, when the atmega is in reset, it's SS/ output is low, so with the pull-up the LS7366R SS/ will be high
[13:40:32] <Thrashbarg> correct
[13:40:46] <superware> while the mega is being programmed, LS7366R SS/ is high, so it's ok
[13:40:51] <Thrashbarg> yup
[13:42:18] <superware> just for the record, I have an attiny2313 running at 20Mhz that does the quadrature encoder counting and acting as an SPI slave, it works, but requires a bit of a delay (1us) at the master between SPI bytes
[13:42:43] <superware> I've decided to try this 32 bit 40Mhz counter
[13:44:59] <superware> only issue I see is that LS7366R Operating Temperature is -25C
[13:45:16] <Thrashbarg> eh?
[13:45:23] <superware> might be a bit high :)
[13:45:46] <superware> for outdoors operation
[13:45:59] <superware> where are you from? :)
[13:46:33] <Thrashbarg> Australia... I know nothing of sub zero temperatures
[13:46:43] <superware> heh
[13:47:25] <Thrashbarg> I was going to ask what you needed -25C or colder devices for... makes sense now lol
[13:47:59] <superware> I wish it was -40
[13:49:14] <superware> I would have stick with the attiny2313 if I knew asm to optimize the (quite simple) external interrupt code
[13:50:32] <superware> http://pastebin.com/vt0h6wxD
[13:53:36] <superware> Thrashbarg: do you think it's possible to get that external interrupt to around 20 ticks?
[13:54:31] <Thrashbarg> I thought you didn't need that now you have a quadrature chip :P
[13:55:55] <superware> that -25C rating might be a party killer
[13:56:02] <Thrashbarg> ah
[13:58:06] <superware> another issue with the attiny2313 solution, is that it would be difficult to separately program (ISP) each chip. might require a 3-pin jumper, all shorted by default...
[13:58:24] <superware> with shared RESET/
[13:58:34] <superware> and that jumper on SCK
[14:02:11] <megal0maniac> superware: Where are you and where will this thing be that -25C is too high?
[14:03:05] <superware> not here, but there are many places with months of sub -25C
[14:06:39] <superware> thanks, bye
[15:40:39] <N1njaneer> So for instance if you stick with thte 1uf cap, you might want to see what the difference is if you go to 1K/1K or 100K/100K on your divider
[15:41:13] <Jartza> yeah, that would be interesting to see with scope
[15:41:31] <Jartza> I played a lot with resistor and cap values just by testing with higher and higher sample rate
[15:41:46] <Jartza> so far these values proved to work best for the current version
[15:41:49] <N1njaneer> You can also consider adding some clamping diodes to help protect the micro's pin. The micro has some internally, but usually a good idea to help better protect it where possible.
[15:41:59] <Jartza> but of course this is mostly guessing as I don't see what's going on
[15:42:08] <N1njaneer> Yeah
[15:42:24] <Jartza> with 1k I didn't get any interrupts at all
[15:42:35] <Jartza> and with 100k I got a lot of errors
[15:42:41] <Jartza> also tried 47k and 4.7k :)
[15:43:34] <N1njaneer> What I'd also suggest doing is write a very short piece of code that immediately toggles another output pin as soon as the INT0 fires on the rising edge. Then scope that output pin on Channel 2 with Channel 1 watching the input waveform, with the two overlayed, because then you'll have a good feel for the point on the waveform where the Atmel detects the rising edge.
[15:44:26] <Jartza> yeah
[15:44:34] <Jartza> I still need to learn how to use the scope also :)
[15:56:01] <Jartza> ok, cool, thanks N1njaneer
[15:56:23] <Jartza> although I don't have a scope, but now this works also with 54k sample rate :)
[15:56:30] <Jartza> with diode
[15:56:46] <Jartza> although, for some reason 1n4148 seems better than bat85
[15:56:53] <Jartza> but with both I get higher samplerate
[15:57:06] <Jartza> bat85 goes up to 52k and 1n4148 up to 54k
[15:57:32] <Jartza> 54k means averate 9kbps
[16:08:08] <N1njaneer> Awesome!!
[16:08:20] <N1njaneer> I'm glad the suggestion seems to have helped.
[16:08:41] <Jartza> yes, eagerly waiting for the scope
[16:08:56] <Jartza> I guess scope is also a nice way to learn what really happens when you do something
[16:09:26] <Jartza> this far I've done things by reading a lot of web, 30% guessing and 40% just trying :D
[16:10:59] <Jartza> although the current speeds of this "dem" are actually way way higher than I ever needed :)
[16:11:01] <N1njaneer> Main difference is probably the 1n4148 having a forward voltage of around 1V and the BAT45 being more like half that
[16:11:18] <Jartza> because I'm going to update the eeprom contents more or less with this
[16:11:29] <N1njaneer> You should be able to see the difference quite easily with the scope :)
[16:11:31] <Jartza> but of course I might implement some other ways to use this
[16:11:48] <N1njaneer> 30%/40% -- it's a good way to learn.
[16:12:11] <Jartza> I'm guessing eeprom update speed is quite much slower than my current speed
[16:12:17] <Jartza> and I was aiming for 400bps :)
[16:12:23] <N1njaneer> The theory is useful, but the practicality of learning how things "feel" by actually doing is generally more conducive to getting things done :)
[16:12:30] <Jartza> "I'm glad if I ever get 400bps to work"
[16:12:44] <N1njaneer> EEPROM in the Atmel?
[16:12:50] <Jartza> yep
[16:12:56] <Jartza> that whole 512 bytes in attiny85 :)
[16:13:12] <N1njaneer> Yeah, writing is generally slow. Just be aware of the finite lifetime.
[16:13:15] <Jartza> maybe I make a bootloader with this
[16:13:42] <Jartza> well the eeprom is going to be written at the most around 1000 times
[16:13:52] <Jartza> usually less
[16:14:12] <N1njaneer> Should be perfectly fine, then.
[16:14:46] <Jartza> outside the update with modem, rest of the time the sw just read the eeprom
[16:15:18] <N1njaneer> I have thought it would be interesting to do a study to write a simple program and run it on about a dozen AVRs - basically just keep writing progressive values to EEPROM repeatedly, then reading them back, then writing, and keep track of how soon the errors begin to show up. Then graph it all.
[16:16:26] <N1njaneer> Atmel generally specificies a minimum of 100K write cycles, but it would be interesting to know when things actually do start dying, or what the maximum number of writes that some byte manages to hold out for :D
[16:17:56] <Jartza> I actually stumbled upon such project
[16:18:02] <Jartza> just a few days ago
[16:18:05] <Jartza> lemme check history
[16:21:22] <Jartza> agh. can't find it as my history seems to be limited to 4 days
[16:21:28] <N1njaneer> Awww
[16:22:26] <Jartza> ahh
[16:22:26] <Jartza> http://tronixstuff.com/2011/05/11/discovering-arduinos-internal-eeprom-lifespan/
[16:22:28] <Jartza> found it
[16:24:12] <Jartza> 1.2 million cycles :)
[16:24:28] <N1njaneer> Interesting. I'd take that one step further, though, and see how the bytes die across the whole thing :D
[16:25:22] <Jartza> :)
[16:28:06] <Jartza> I also tested my modem for errors by sending the "pride and prejudice"-book through :)
[16:28:14] <Jartza> then I captured the log from my terminal and ran diff to it
[16:28:21] <Jartza> 20 sends, 0 errors
[16:28:44] <Jartza> and those were sent from different devices
[16:29:12] <Jartza> macbook pro, nexus 4, samsung galaxy s3, jolla, asus tf300 and ipad mini
[16:29:31] <Jartza> I'm still thinking to maybe implement some simple error correction
[16:29:34] <Jartza> like hamming code etc
[16:29:58] <Jartza> or I might create also a channel to talk back
[16:30:44] <Jartza> maybe use a crc, send 8 bytes and then acknowledge the sender if the crc was ok or if the block needs to be re-sent
[16:31:02] <Jartza> that wouldn't require too much bandwidth for the return channel
[16:33:51] <Jartza> and especially if I ever want to try to make a bootloader out of this, backchannel would be must :
[16:35:13] <N1njaneer> Sounds promising!
[16:35:37] <N1njaneer> brb
[16:52:12] <Jartza> 56k sampling rate now, ~9333bps
[16:52:14] <Jartza> whoa
[16:54:57] <aandrew> Jartza: nice
[16:55:34] <aandrew> I'm looking at implementing something tangentially similar. I ahve a bunch of sensors that send periodic data over a shared RS485 link (unidirectional transfer, sensors -> data collector)
[16:56:28] <aandrew> looking at implementing either a basic hamming code or maybe something as simple as transmitting data 3x so that if two sensors transmit over one another it's possible for both messages to get through
[16:57:49] <Jartza> I also thought transmitting blocks of data multiple times, with crc
[16:58:09] <Jartza> like 8+1 byte blocks twice, but now sequentially
[16:58:21] <Jartza> like 0, 1, 2, 0, 1, 2, 3, 4, 5, 3, 4, 5, etc
[16:58:38] <Jartza> then any 3 blocks can "mangle" if I get some error burst and I still get data intact
[16:59:41] <Jartza> but this looks to work stupendously reliably so maybe hamming is enough
[17:10:31] <N1njaneer> That's awesome! Nice work. :D
[17:11:16] <Jartza> thanks :)
[17:16:51] <Jartza> well, 56k sampling rate seems to now work also with 10uF capacitor
[17:16:59] <Jartza> so I guess the diode did quite much
[17:17:24] <Jartza> although, I will probably run it on 48k, 8000bps is more than enough
[17:17:26] <Jartza> or even 32k
[17:17:33] <Jartza> just more reliable, I gues
[17:19:39] <Jartza> but just out of curiosity, I'll run the book through it once with 54k / 9kbps average
[17:21:01] <aandrew> Jartza: where'd you put the diode?
[17:21:47] <Jartza> 23:13 < N1njaneer> You can also add a reverse-biased diode to ground after the cap to push the resulting level a bit, too.
[17:21:51] <Jartza> like so
[17:22:46] <Jartza> 23:14 < N1njaneer> Jartza: Meaning you'd attach the + of the diode the ground and the - side to the output of C1 -- keeps the signal from flowing straight to ground once it exceeds the forward voltage of the diode.
[17:32:00] <Jartza> whoh
[17:32:17] <Jartza> zero faults, average speed for the book 1133 B/s
[17:34:19] <Lambda_Aurigae> nice.
[17:34:31] <Lambda_Aurigae> you gonna release that code?
[17:34:51] <Jartza> I'm hoping to
[17:34:53] <N1njaneer> Yay I was helpful! :D
[17:35:24] <Jartza> unfortunately I've done this mostly on my companys resources (and also on some time, I've been gladly given some paid time for crazy prototyping)
[17:35:45] <Jartza> so basically the company "owns" the code
[17:35:55] <Jartza> but I'm guessing some sort of dual-license would be o
[17:35:56] <Jartza> ok
[17:36:21] <Jartza> free for hobby/personal use/opensource projects and if you really really wish to use it commercially, then contact us :)
[17:36:38] <Jartza> still, I need to make sure
[17:37:01] <Jartza> but I guess lot of hobbyists would maybe find the code useful
[17:37:13] <Lambda_Aurigae> I can think of a use for it.
[17:37:15] <Jartza> at least it's a dirt-cheap way of transferring data to avr from almost any device
[17:37:28] <Lambda_Aurigae> I was thinking eliminating the wire a
[17:37:38] <Lambda_Aurigae> and going audio-over-the-air
[17:37:55] <Jartza> Lambda_Aurigae: well, get back to me tomorrow, my boss promised to get back to me on monday :)
[17:38:01] <Jartza> hmmh
[17:38:10] <Jartza> this might not work over-the-air that well, can't be sure though
[17:38:21] <Lambda_Aurigae> by air, I mean air, sound.
[17:38:22] <Jartza> this is not a traditional modem-modulation
[17:38:31] <Lambda_Aurigae> you are using audio though, yes?
[17:38:34] <Jartza> but you'll never know, haven't tried
[17:38:38] <Jartza> yes, cable
[17:38:53] <Jartza> from headphone-plug of phone/tablet/laptop/mp3-player/whatnot
[17:39:10] <Jartza> it might just work with audio too, haven't tried
[17:39:13] <Jartza> I have no microphones :D
[17:39:14] <Lambda_Aurigae> ever hear of acoustic coupled modem?
[17:39:20] <Jartza> yes
[17:39:39] * megal0maniac didn't realise that was a thing
[17:39:40] <Lambda_Aurigae> might have to dramatically cut the speed, but, still something to play with.
[17:39:51] <Jartza> sure
[17:39:57] <Jartza> at least the whole idea is dead-simple
[17:40:05] <Lambda_Aurigae> http://en.wikipedia.org/wiki/Acoustic_coupler
[17:40:26] <Lambda_Aurigae> I remember using those.
[17:40:49] <Jartza> Lambda_Aurigae: I had one of those too, 300 baud
[17:41:22] <Lambda_Aurigae> yup.
[17:41:26] <Jartza> inside sound-isolating big box, I just opened it to dial the connection and then close the lid so less errors :D
[17:42:11] <Lambda_Aurigae> mine had nice foamy covers around the connections for outside noise dampening.
[17:44:25] <Jartza> yeah, foam inside the box, I had that :)
[17:44:53] <Jartza> but my "modem" sounds more like...hmm... a dentist drill :)
[17:45:25] <Jartza> something between 6-12kHz sound :)
[17:46:48] <Jartza> I just realized something
[17:47:12] <Jartza> I guess the limit of my modem speed is also something to do with the timer
[17:47:34] <Jartza> if I set the prescaler to 256 instead of 512 I might make it go faster :)
[17:47:45] <Lambda_Aurigae> possibly.
[17:48:44] <Jartza> Program: 344 bytes (4.2% Full)
[17:48:59] <Jartza> that includes the "modem" and uart-tx @115.2k
[17:49:15] <Jartza> it's just receiving from audio signal and echoing back to serial port
[18:11:38] <N1njaneer> Jartza: Now add XMODEM -- it does CRC error correction and retry automatically, and most comm software can handle it just fine. I've implemented it a few times for bootloader support :)
[18:12:08] <Jartza> N1njaneer: yeah, but that needs 2-way comm :)
[18:12:24] <N1njaneer> Ahhh true. :D
[18:12:34] <N1njaneer> Well... Write it on the PC side, too! :D
[18:12:42] <Jartza> the only reason I started to even think the whole modem was that I only have 1 pin to spare :)
[18:12:56] <Jartza> but I was thinking some kind of half-duplex
[18:13:04] <N1njaneer> Sure - do bi-directional
[18:13:12] <N1njaneer> I've done that for XMODEM over RS485
[18:13:21] <Jartza> yeah
[18:13:42] <Jartza> but I have no clue whatsoever yet how to connect everything together :)
[18:13:49] <Jartza> so using 1 pin for both input & output
[18:14:28] <Jartza> actually the return channel could have much slower speed
[18:16:02] <N1njaneer> Very true.
[18:16:19] <Jartza> something like 300bps would be quite enough, even slower
[18:23:20] <Jartza> well... with 8000bps this is virtually error free from all my devices
[18:23:30] <Jartza> except of course, when someone calls me when I'm testing :D
[18:26:26] <Jartza> I would be surprised if I didn't get a permission to release the source
[18:26:32] <Jartza> as the ISR-function is 13 lines of C
[18:26:34] <Jartza> :D
[18:26:38] <Jartza> stupidly simple
[19:07:20] <Jartza> oh well. off to sleep ->
[21:22:55] <umquant> rue_more: and N1njaneer: sorry for missing your messages on the 4-20ma stuff. Thank you for the insight
[21:23:42] <umquant> As a POC you think I could get buy with just using a 250ohm resistor? It is a 24v source system.]