**** BEGIN LOGGING AT Fri May 15 02:59:57 2020 May 15 04:33:19 I see the BBGG has a VBAT expansion port. Nice. May 15 04:34:35 What size battery voltage does the VBAT terminal accept? May 15 04:40:07 12v? May 15 06:36:08 do not use VBAT May 15 06:36:47 it is meant for direct connection to single-cell lithium-ion, but it is not officially supported and has too many problems to be usable in practice (for most people) May 15 11:15:19 hmm, should I try cross compiling libiio? I really don't like hardcoding paths like /sys/bus/iio/devices/iio:device1/out_voltage0_raw May 15 11:15:25 that's just asking for trouble May 15 11:58:56 hmm probably May 15 12:43:27 zmatt sorry if I missed you if you commented; here are the scope traces. Looking at the se outputs, seems liek they're not quite clean https://drive.google.com/open?id=1NrGKgovlHJQXln2VcAOdT3Gg1qv5-vtF May 15 12:43:52 I did realize I don't have a terminating resistor on the inputs of the receivers, I'm going to do that today, turn on the BW limit on the scope and check again May 15 12:44:02 and make sure my ground is nice and tight May 15 13:49:15 oh that doesn't look pretty May 15 13:50:55 what type of environment do you have there? that looks like a lot of switching transients, LED lighting? I'd make sure my probing is watertight... May 15 13:56:10 It's on a wooden work bench in my garage, not a lot of noise at all and 2 typical house LED light bulbs on the ceiling May 15 13:56:29 I'm make shifting a couple spring clip grounds instead of alligator clips and going to add a pullup to the output May 15 13:56:43 See if that cleans it up thinkfat_ May 15 14:03:20 hmm you may wish to fly a lead from a close ground to the signals and clip to that. The alligator clips on scope leads sometimes aren't particularly useful. It would be nice if they offered a method to connect to a header. May 15 14:06:09 a shorter ground loop can certainly help May 15 14:07:35 GenTooMan I'm running some super thin wire around it making my own spring clip ground that will go into the breadboard. May 15 14:08:01 thinkfat_ thats' what I'm thinking. The encoders are counting up with no regard to motor direction (both directions count up), I think it's a noise issue. May 15 14:08:30 So I'm going to add a terminating resistor between a+ and a-, add a pullup on the output and then make the ground probe short and see if that cleans it up and fixes the issue May 15 14:15:45 biggi_: is "ase-bse" measured on the output of the differential receiver? May 15 14:18:10 thinkfat_: instead of hardcoding paths you could just use an udev rule to create stable paths May 15 14:18:38 zmatt: hm, not so nice for iio.. May 15 14:18:53 (or just use libiio) May 15 14:19:26 "not so nice for iio" ? yeah making symlinks for sysfs paths is a bit uglier than making them for devices, but still quite doable May 15 14:19:52 libiio, yes, that's what I was thinking. I just need to cross compile it. As I don't develop directly on the target I need it within the linaro sysroot May 15 14:21:25 biggi_: normally quadrature encoded signals are fairly noise-resistant (since any noise spike that occurs on only one of the two lines while the other is stable is ignored), but perhaps this is just too terrible for eQEP to cope with? I wonder if it's giving any quadrature decoding errors (that are probably ignored by the driver) May 15 14:22:24 biggi_: also for a+/a- and b+/b- it may be useful to use twisted pairs (e.g. two pairs of a cat5 cable) to maximize noise immunity May 15 14:23:06 what's the impedance of the outputs? May 15 14:23:13 unspecified May 15 14:23:18 ^ yup May 15 14:23:43 ok, how much current can they source? May 15 14:23:47 unspecified May 15 14:23:54 zmatt guy at work suggests pull up on the output of the receiver May 15 14:24:10 biggi_: why? May 15 14:24:13 it's a push-pull output May 15 14:24:31 zmatt "If you look at the output of the receiver it shows a low side transistor switch. Those always have to be pulled up. When it turns on you need a large enough pullup resistor or there won't be enough voltage drop to get to ground." May 15 14:24:46 really? May 15 14:24:51 what? what receiver are you using? May 15 14:25:02 same one i have been.... May 15 14:25:04 sec i'll link May 15 14:25:14 yes but I don't remember stuff like that :P May 15 14:25:16 https://www.ti.com/lit/ds/symlink/am26lv32.pdf?&ts=1589506367588 May 15 14:25:56 your guy at work is talking poop May 15 14:26:15 it's a push-pull cmos output May 15 14:26:16 I typically trust him fairly well May 15 14:26:23 Will a pull up hurt? May 15 14:27:06 he probably glanced at the diagram too quickly, there are two transistors located near the output but they seem to be part of ESD protection May 15 14:27:16 yep, figure 8, that's a totem pole driver May 15 14:27:18 Note: I don't have R_term either May 15 14:28:33 So back to the other question too: would a pull up hurt? May 15 14:28:37 biggi_: termination at the end is not needed if the output impedance of the encoder matches the characteristic impedance of the line, and using parallel termination at the end may result in too much current consumption for the output of the encoder to handle May 15 14:28:52 (we have no way to know without proper electrical specs) May 15 14:29:10 Which unfortunately I don't have May 15 14:29:24 Because the ME on the project specc'd the motors and designed around them so I'm specc'd into a corner sadly. May 15 14:29:24 also, ringing on a quadrature encoded signal isn't really a problem as long as it dies out before the next encoder step May 15 14:29:26 May try emailing them May 15 14:29:35 datasheet says the outputs can source and sink 5mA May 15 14:29:58 ah it does? I remembered it specified very little, should have double-checked May 15 14:30:11 okay so that excludes parallel termination May 15 14:30:14 Output current of the encoder is 20ma May 15 14:30:22 ehh May 15 14:30:33 https://www.omc-stepperonline.com/Nema-17-Closed-loop-Geared-Stepper-L34mm-Gear-Raio-271-Encoder-1000CPR.html May 15 14:30:38 Output current of the encoder IS 20ma. May 15 14:31:25 The description page of the motor has more info than the datasheet. May 15 14:31:33 oh nice, by which I mean "dumb as shit" May 15 14:31:36 but that is not a current loop, is it? May 15 14:31:50 biggi_: anyway, that's still not enough for proper termination May 15 14:31:59 parallel termination I mean May 15 14:32:09 So no need for that? May 15 14:32:18 so option for that, regardless of need May 15 14:32:22 *no option May 15 14:32:38 but like I said, ringing is probably not a big problem anyway May 15 14:32:50 So I still don't like the noise. Figuring that might have something to do with the eqep not reading properly May 15 14:32:53 and could be controlled by series termination at the source May 15 14:33:00 yeah May 15 14:33:15 so now the question is how to remove it May 15 14:33:22 again: guy at work suggests pull up. May 15 14:33:26 so earlier I asked but you never answered: is ase_bse the outputs of the differential output? May 15 14:33:31 again: guy at work is wrong May 15 14:33:35 Yes May 15 14:33:37 he misread the datasheet May 15 14:33:44 ase_bse are the single ended outputs May 15 14:34:34 and you grounded the probes to the ground of the differential receiver (which should also be the ground of the BBB) May 15 14:34:38 ? May 15 14:34:57 I grounded them to the ground rail on the breadboard which is also tied to the receiver and the BBB May 15 14:35:08 *tied to digital gnd on the bbb May 15 14:36:09 what sort of wiring are you using between the encoder and the receiver? May 15 14:36:21 22 awg solid May 15 14:36:29 well May 15 14:36:54 but not twisted pairs? and you're running them parallel to the wires that drive the motors? May 15 14:36:55 I soldered wire onto the encoder wires and ran those to the receiver (as nobody here has db connectors) May 15 14:37:06 No, they're not near the motor wires May 15 14:37:11 no twisted pairs May 15 14:37:21 just solid wire soldered on going to receiver (that is maybe 6" long tops) May 15 14:37:40 I can clean it up a bit this afternoon and see if that helps maybe. May 15 14:37:46 And send you a picture May 15 14:37:58 some zoom-in might be informative to see what sort of noise this is May 15 14:38:34 So let me do a few things: I need to get kids lunch here in a bit then when they go down for nap (probably here in about 2 hours) I'll run out, clean the wiring up super well and get a nice clean shot of wiring and then zoom in to see the noise May 15 14:38:37 Sound good? May 15 14:38:47 (btw: not being sarcastic or anything. truly appreciate the help) May 15 14:39:01 If I could tip ya'll I would. Have a btc wallet address? XD May 15 14:39:11 no need May 15 14:40:07 I guess you just need to debug how the noise is being picked up, and figure out how to either prevent it from being picked up and/or how to suppress it (e.g. some RC filter on the receiver input) May 15 14:40:12 I know; I do truly appreciate it though. Trying to figure this out at home is kinda wonky sometimes haha May 15 14:40:55 I don't know what timezone you're in, but I'll get a few shots here soon and be back on May 15 14:41:17 I'm in a custom timezone (my sleep schedule isn't great) May 15 14:42:11 I know the feeling. Like I said, it'll be a few hours and we'll go from there May 15 15:56:32 is the cpsr register banked, e.g., on privilege level? May 15 16:04:45 yates: on armv8, certainly, armv7 doesn't really have privilege "levels" May 15 16:04:54 yates: but the cpsr is still banked. May 15 16:11:14 armv7 does have privilege levels May 15 16:11:20 the armv8 term is "exception level" May 15 16:11:36 but cpsr isn't merely banked on privilege May 15 16:11:47 wait actually, no, it's not banked May 15 16:11:59 at all May 15 16:16:18 spsr is banked between the six exception modes (irq, fiq, supervisor, abort, undefined, and (with security extensions) secure monitor) May 15 16:16:46 each of these also have their own copy of SP and LR (separate from the SP and LR used by user mode and system mode) May 15 16:16:56 but there's only one CPSR May 15 16:19:22 the processor mode (which determines privilege level) is part of the CPSR so banking it is intrinsically nonsensical May 15 16:23:09 (armv7 virtualization extensions adds hyp mode which again has its own SPSR and SP, though instead of having its own banked LR, the return address for hypervisor traps is stored in a completely separate register "ELR_hyp") May 15 16:28:57 see figure B1-2 in section B1.3.2 on page 1144 of the latest (2018, rC.d) version of the ARMv7 architecture reference manual May 15 16:37:15 zmatt: that's what i suspected. May 15 16:37:42 the problem is that i'm trying to set the E bit in assembler but it doesn't look like it's getting set: https://paste.centos.org/view/b895aa2d May 15 16:37:50 i can read it into r1, and the orr sets the E bit, but msr does NOT set it (as evidenced by reading it back via p/x $cpsr) May 15 16:38:07 (this is using arm-none-eabi-gdb) May 15 16:38:11 and qemu May 15 16:39:24 is this perhaps a qemu issue? May 15 16:40:59 you're trying to change endianness? that requires using the "setend" instruction May 15 16:41:17 data endianness only May 15 16:41:24 yeah that's the only one you can change May 15 16:42:01 why can't you set it directly in the cpsr? May 15 16:43:10 "At PL0, a read of the CPSR by an MSR instruction returns an UNKNOWN value for the E bit, and a write by an MSR instruction has no effect on the E bit." May 15 16:43:51 is the processor at PL0 on reset? May 15 16:43:57 this is right after reset May 15 16:44:41 no, PL1, so then accessing it ought to work on ARMv7-A/R systems although it is deprecated May 15 16:44:51 or in this case, right after starting gdb May 15 16:44:55 ok. May 15 16:44:56 what cpu are you emulating? May 15 16:45:00 a9 May 15 16:45:16 cortex-a9 May 15 16:46:02 might be a qemu bug that went unnoticed since it only affects operations which are deprecated anyway May 15 16:46:39 try using setend to change it and confirm it by loading a value using ldr May 15 16:46:43 i think you're right though. i had tried setend be and my branch went into the weeds, which is misinterpreted as a change in opcode endianness. May 15 16:47:01 *which i had* May 15 16:47:02 endianness never affects instruction fetch May 15 16:47:35 you mean there is no way to change instruction fetch endianness at run time? May 15 16:48:06 i believe it is (at least) configurable in the hardware, right? May 15 16:48:35 "In ARMv7-A, the mapping of instruction memory is always little-endian." May 15 16:48:48 hmm. May 15 16:49:05 i guess i was confyoosed May 15 16:50:14 ARM v7-R and -M allow instruction endianness to be configured, but it's done by a cpu input that's sampled at reset, it cannot be changed at runtime May 15 16:50:30 since there's no sane way to deal with the transition May 15 16:52:27 * yates looks for the gcc option to make literals BE (without manually switching bytes) May 15 16:52:47 -mbig-endian May 15 16:52:55 maybe? May 15 16:53:12 or does that affect code? May 15 16:54:32 yes, that's code May 15 16:54:37 nice try! May 15 16:55:30 hmm. i don't see any such option. May 15 16:59:55 that's really bizarre, that it'll generate big-endian code for a cpu that doesn't support it May 15 17:00:28 guess they expect you to know what you're doing.. May 15 17:00:51 in general the options march override mcpu, so that kinda makes sense May 15 17:01:23 e.g., i'm using arm-none-eabi-gcc -c -o hp9010-bootrom.o -mcpu=cortex-a9 hp9010-bootrom.S May 15 17:01:44 neither the architecture (armv7-a) nor the cpu support big-endian instructions May 15 17:03:21 "Note: If a program is being built for a system with big-endian data and little-endian instructions then it should be assembled with the -EB option, (all of it, code and data) and then linked with the --be8 option. This will reverse the endianness of the instructions back to little-endian, but leave the data as big-endian." May 15 17:03:56 (-- GNU assembler manual) May 15 17:12:24 were you passing -mbig-endian also while linking your program? May 15 17:12:32 if that doesn't suffice, try adding -Wl,--be8 May 15 19:07:20 it was just one address - i reversed it manually. May 15 19:07:52 my make recipe: arm-none-eabi-gcc -c -o $(FILE).o -mcpu=cortex-a9 $(FILE).S May 15 19:08:28 works now with the setend instruction May 15 19:08:46 I mean... a .o file is not something intended to be run directly May 15 19:09:13 did i say i intended it to be run directly? May 15 19:09:32 well I don't understand why you'd have to reverse anything manually instead of adding the correct linker option May 15 19:09:34 there is a link recipe as well May 15 19:09:53 (compiler and linker options) May 15 19:10:05 because dicking with the options would be >0.5 hour and reversing the bytes is about 0.005 hours May 15 19:10:51 passing -mbig-endian to gcc (for compiling and linking) and, if that doesn't suffice, adding -Wl,--be8 when linking would take half an hour? May 15 19:11:46 it is my choice, and i don't plan on changing it at the moment. thanks for your help, though. May 15 19:18:05 zmatt cleaned up wiring a bit, getting ~1.5v of just noise coming off the encoder May 15 19:18:08 on the single ended output May 15 19:18:41 All the individual sections to the inputs don't have the noise May 15 19:18:58 ehh what May 15 19:19:17 If I probe A+, it looks fairly good by itself. When I look at a_se, it's noisy af May 15 19:19:41 the output of the differential receiver is noise even though the inputs aren't? May 15 19:19:54 yes May 15 19:20:16 just to confirm, the inputs are not at the same level right? (they should never be, A- should be low when A+ is high and vice versa) May 15 19:24:54 your previous scope shots showed pretty noisy A+/A- as well, what did you do to make that noise go away? May 15 19:26:16 do you have screenshots? May 15 19:54:12 Good evening May 15 19:54:17 Still some humans on here? May 15 19:54:27 Or only bots? May 15 19:55:07 just you and 149 bots May 15 19:55:18 beep boop May 15 19:55:23 I think it's probably the other way 'round May 15 19:55:45 But you never know with bots these days May 15 19:58:26 Eliza the bot talks endlessly.. May 15 19:58:35 :) May 15 19:59:57 Probably some lurkerbots around too, since they aren't responding. May 15 20:00:20 Perhaps they are just napping to preserve energy. May 15 20:01:12 that said .. need anything before the real bots turn into lurkers? May 15 20:09:02 zmatt sorry, something went wonko and i couldn't reconnect May 15 20:09:11 a+ and a- are perfect inverses and no noise at all May 15 20:09:39 The output has lots of base noise, put a 4.7k pullup to 5 and it got rid of the base noise, but there's noise in the signal. May 15 20:10:00 I'm going to try another chip, maybe I damaged this one somehow by overheating when soldering and trying again, if not, the encoder itself looks great May 15 20:10:01 "a 4.7k pullup to 5" ??? May 15 20:10:14 sorry, was just testing with no beaglebone May 15 20:10:27 moved the vcc of the chip to 5 to see if my 3.3v regulator was messing up May 15 20:10:42 pull up to 3.3V when VCC = 3.3 and pull up to 5 when vcc = 5v May 15 20:10:56 It's just the output signal being weird. May 15 20:11:34 that had any effect? there's no logical explanation for that, unless you forgot to enable the receiver's output (but then I wouldn't expect any signal) May 15 20:11:57 With no beaglebone on it, it just put a load on the line May 15 20:11:58 unless indeed the receiver got damaged maybe May 15 20:12:03 So it got rid of the random noise May 15 20:12:26 And to your point: I'm going to replace it and see if I overheated when soldering May 15 20:12:37 load should have no effect on noise on a low-impedance output May 15 20:12:51 :shrug: it did May 15 20:13:06 I've got my backup plan too of just running single ended through a level shifter :) May 15 20:13:17 So I'll have it working Monday, then maybe come back to this if a new chip doesn't fix it May 15 20:13:57 damage to the receiver does start to sound like the most logical explanation of the bizarre behaviour you're describing May 15 20:14:09 that or possession by evil spirits May 15 20:14:21 I do seem to have a knack for finding issues like this :) May 15 20:14:33 (but I don't think a pull-up would help against those) May 15 20:14:49 It might... May 15 20:14:54 (not in electrical terms) May 15 20:15:13 ...biggi made a semi funny joke about kids pull ups and being tormented by evil spirits May 15 20:15:19 I should probably leave now... May 15 20:18:54 * zmatt sips his tea in silent judgement May 15 20:26:34 hmm May 15 20:28:00 thinkfat_: not sure if you caught it earlier, but cpsr is actually not banked :) May 15 20:28:06 the output impedance can be low, but if you have enough wire between source and sink, it will still pick up high frequency stuff.. depends on the length of the wire, though May 15 20:28:29 yes, I got it. yes, it's not banked. it's copied into the spsr on exception. May 15 20:28:36 I mean, he's just measuring the output of the receiver, so I'm assuming the wire length is negligible May 15 20:28:54 hm, indeed May 15 20:29:06 and there's no noise on the input? May 15 20:29:40 I thought the scope traces were on the input of the receiver, not the output... May 15 20:29:48 on the output, that's weird May 15 20:30:24 he had both, but that was an earlier measurement so maybe he did something to get rid of that noise, dunno (I asked but it didn't get answered) May 15 20:31:10 I mean, if there's noise on the input then you'll probably also get noise on the output (unless it's common-mode noise) May 15 20:31:42 but that sort of noise on an output can only come from the supply May 15 20:31:52 or from the probing ;) May 15 20:32:18 *shrug* May 15 20:32:57 he hasn't shown images of the latest measurements so I don't know what he saw May 15 20:55:09 hm, the output circuit of that receiver chip looks weird. could be some kind of clamping circuit, the transistors being used in their breakdown region like zener diodes May 15 20:57:23 yeah I haven't studied that circuit in much detail, it just seems fairly obviously some sort of overvoltage protection that's vcc-independent, since there's no clamp diode to vcc May 15 20:59:12 now that you mention it, the circuit does looks odd, with base and emitter tied together for both transistors... that's not how one would normally use a transistor May 15 21:01:40 hmm, that circuit would conduct if Y is negative (relative to GND) right? May 15 21:02:52 but then again there's already a schottky from GND to Y to deal with that scenario May 15 21:03:45 base and emitter tied is exactly how you'd use it in "reverse breakdown" mode ;) May 15 21:09:13 hm, or not. May 15 21:09:56 weird. it's too late. I need some sleep. **** ENDING LOGGING AT Sat May 16 02:59:57 2020