**** BEGIN LOGGING AT Tue May 15 03:00:02 2018 May 15 09:32:45 i have BeagleBone Black Wireless, and i what to change the freq: frequency of the PWM in Hz (default is 2kHz) to Other default frequency! How can I do that May 15 09:33:09 please help May 15 09:35:11 I have Debian 8.6 on my board May 15 13:41:06 I think the frequency is simply configurable along with the duty cycle? May 15 13:41:53 e.g. when using bonescript you can pass frequency as extra argument to analogWrite May 15 14:24:22 hey guys, I was searching on the internet for a c++/c lib to controll the PWM on beagle bone black, does someone have a suggestion? May 15 14:25:36 bjoekeldude: well there isn't much to be libraried. you just write values to the appropriate sysfs attributes (which are represented by files in sysfs, and behave more or less like files) May 15 14:26:03 just use open() and write() May 15 14:28:10 okay, thanks for this tip. but is there somewhere a documentation on the specific attributes i may set? May 15 14:29:16 i mean, right now, im using config-pin to set my pin to pwm. after that i'm using the node and bonescript. but that takes so much time May 15 14:29:39 i mean, there is like a latency of.... seconds until the pwm reacts May 15 14:30:04 that sounds really weird, nodejs shouldn't be *that* slow May 15 14:30:27 it is hell.... May 15 14:30:49 "so much time" May 15 14:30:55 can be anything from 2ms to 2s May 15 14:30:57 or more May 15 14:31:04 i'd like to run a PID controller in the background of my bbb controlling a PWM servo May 15 14:31:20 right now it is 8s latency May 15 14:31:21 but anyway, if you look around in /sys/class/pwm it should hopefully be reasonably self-explanatory. docs for the sysfs interface can be found here: https://www.kernel.org/doc/Documentation/pwm.txt May 15 14:31:54 the main tricky part is correctly identifying the pwmchip devices, since the kernel just sequentially numbers them May 15 14:32:24 wait what? May 15 14:32:36 probably the bbb is busy with something else, so node get scheduled out of the way. and as it is never deterministic, it can be used for super slow and uncritical controls only anyways. May 15 14:33:20 there is definitely way too much crap going on on a bbb by default May 15 14:33:36 ahh now I get it ;) and see the pwms in /sys/class May 15 14:34:12 i'll try. thanks for your great help! May 15 14:34:28 .... hey, i like crap May 15 14:35:30 I'm not sure how bonescript correctly identifies the pwmchip devices... in general my preference is to use udev rules to make symlinks with useful names (typically set in DT), but it's also possible to use libudev to identify devices May 15 14:36:08 but they should be always the same after reboot right? May 15 14:37:52 probably. relying on that is still really fragile though and can easily break if you upgrade the kernel or when you end up needing to use DT overlays May 15 14:38:10 the kernel definitely makes no such guarantee May 15 14:39:10 some devices do have stable numbering (defined in DT) such as i2c and spi, but afaik this isn't the case for the pwm devices May 15 14:41:12 but yeah, unfortunately there are probably way too many people who nevertheless hardcode such numbers in their software May 15 14:41:56 (technically the same is true for gpio numbers, although they less likely to change in practice) May 15 15:13:26 thanks @zmatt May 15 15:59:23 hmmm when i try do `echo rising > edge` on my gpio pin, it says 'error: device or resource busy` May 15 15:59:28 not sure what its doing... May 15 15:59:37 my pin is an input put May 15 16:04:01 that's odd May 15 16:04:22 that shouldn't happen unless the pin is configured as output May 15 16:06:22 seems like its because its a gpio-key May 15 16:06:32 so I guess it forces it only certain ways May 15 16:06:40 uhh, okay so it *is* busy May 15 16:06:57 gpio-key will already have claimed the pin's irq May 15 16:07:10 ah I see May 15 16:13:38 zmatt: funny that I can write "both" into the edge file May 15 16:13:49 even though the gpio key is configured to be ACTIVE_HIGH May 15 16:15:25 why? gpio-key obviously wants to know both when the key is pressed and when it's released May 15 16:15:48 so it'll request edge=both regardless of whether the gpio is active-low or active-high May 15 16:15:55 actually May 15 16:16:00 I think that's configurable in DT May 15 16:16:52 or wait, no, that's just for wakeup May 15 16:20:44 yeah it always requests 'both': https://github.com/beagleboard/linux/blob/4.14/drivers/input/keyboard/gpio_keys.c#L569 May 15 16:22:03 so the active-high in the dtbo file for the gpio-key is wake up on high? May 15 16:22:12 no, active-high is active-high May 15 16:22:31 oh May 15 16:23:35 active-high means the gpio is high when active/asserted/"logic 1" and low when inactive/deasserted/"logic 0" May 15 16:23:41 while active-low means the opposite May 15 16:23:56 oh I see May 15 16:24:46 but it interrupts on both rising and falling edge May 15 16:24:57 thats what you were saying right? May 15 16:25:10 buttons are usually active-low (i.e. the button is connected between the gpio and ground, and the pin has a pull-up to vdd), but it can also be active-high such as in your case apparently May 15 16:27:00 it requests irq on both edges yes, for debouncing (and for autorepeat, if enabled) May 15 16:27:58 I see May 15 16:28:12 actually, what am I saying, both key press and key release generate events to userspace, so *of course* it needs irq on both edges, even in the absence of debouncing or autorepeat May 15 16:31:31 right May 15 17:00:45 so I have an external sensor that I want to have interrupt me when it senses something, while its not interrupting me, both the sensor May 15 17:00:52 and the device controlling it will be asleep May 15 17:01:39 is there a right way to have both interact such that race conditions can be prevented May 15 17:01:48 I don't even know if my question makes sense May 15 17:03:39 assuming level interrupts are used (and I've never seen a peripheral device that doesn't) there isn't really any race condition possible May 15 17:04:02 I hope this isn't related to your gpio-keys thing, which isn't designed for this purpose *at all* May 15 17:04:20 it kinda is May 15 17:04:46 but this is interesting, what particularly isn't designed for this purpose here? May 15 17:04:48 gpio-keys is designed for (surprise!) keys May 15 17:04:56 things pressed by humans May 15 17:05:15 ok, so how would I get an interrupt to wake me from sleep then? May 15 17:05:50 I seem to recall, when i originally investigated the interrupt thing, that GPIO pins don't let you wake up the device from sleep May 15 17:06:16 its entirely possible, that I overlooked something May 15 17:06:53 I'm pretty sure any interrupt that's enabled while the device is sleeping will wake it up (unless deepsleep is used, where the options are more restricted) May 15 17:07:27 ye I need the lowest sleep state possible May 15 17:10:21 in deepsleep the wakeup sources available are: any pin of gpio0, timer1, usb resume signalling, adctsc, uart0, i2c0, and the rtc May 15 17:10:49 I've never really dug into the details of how this is managed by linux though May 15 17:11:17 hmmm May 15 17:11:20 time to test this again May 15 17:12:37 it looks like a driver needs to have explicit support for wakeups May 15 17:12:48 e.g. gpio-keys does May 15 17:14:05 it does look like it's pretty simple to add such support though May 15 17:16:01 okay these are pretty awesome slides... https://www.linuxsecrets.com/elinux-wiki/images/d/dd/Intro_Kernel_PM.svg May 15 17:17:07 such a driver might already exist somewhere May 15 17:17:16 "such a driver" ? May 15 17:17:16 * TonyTheLion hopes he doesn't have to go write it May 15 17:17:37 you said it needs explicit driver support for wakeups May 15 17:18:02 I'm guessing your sensors are some obscure things that don't have existing kernel drivers? May 15 17:18:24 I haven't installed any drivers for any of them May 15 17:18:47 what sensors are they? May 15 17:18:47 my accelleration sensor, is a icm 20649 May 15 17:19:25 thats the only sensor that will interrupt the system May 15 17:21:30 hmm, the inv_mpu6050 driver supports "Invensense MPU6050/6500/9150 and ICM20608 motion tracking devices" May 15 17:21:43 is the ICM20649 very different? May 15 17:22:42 I guess a generic solution might be to add wakeup support to uio_pdrv_genirq ... that can deliver any irq to userspace May 15 17:24:32 anything related to this: http://catch22.eu/beaglebone/beaglebone-pru-uio/ ? May 15 17:24:45 no May 15 17:24:53 I mean, apart from both using uio May 15 17:25:01 ah May 15 17:25:40 it would be pretty nice to support wakeup-source; on uio devices.. and it looks like it might not be tricky... lemme see May 15 17:29:04 (extending that to wakelocks might be trickier, but not needed for your application May 15 17:29:07 ) May 15 17:45:09 TonyTheLion: can you may try to see what happens currently when delivering a gpio irq to userspace via uio? my py-uio project has a DT example ( https://github.com/mvduin/py-uio/blob/master/dts/gpio-irq.dtsi ) and test script ( https://github.com/mvduin/py-uio/blob/master/other-examples/gpio-irq.py ) May 15 17:45:25 sure May 15 17:46:48 it's still edge-triggered since I couldn't really give a standalone example for level-triggered (since it would need some external device that's producing the irq signal) but it should suffice for a quick test May 15 17:48:47 my main concern would be whether it blocks suspend May 15 17:51:15 ok I've configured the pin, so I need to just run the script May 15 17:52:34 yes, it just prints "ping!" every time the interrupt happens (i.e. the edge or level defined in dt) May 15 17:53:17 oh, you'll need to ensure the symlink gets made, either using an udev rule ( https://github.com/mvduin/py-uio/blob/master/etc/udev/rules.d/10-of-symlink.rules ) or by creating it manually for a quick test May 15 17:55:13 zmatt: hmmm doesn't show up in /dev/uio May 15 17:55:21 or even /sys/class/uio May 15 17:55:49 is your system maybe lacking https://github.com/mvduin/py-uio/blob/master/etc/modprobe.d/uio.conf ? May 15 17:55:57 it should be present on standard beaglebone images May 15 17:56:33 weirdly thats missing May 15 17:56:40 I'm running a standard system May 15 17:56:50 I shall go ahead and copy that there May 15 17:57:43 and it also needs to be explicitly probed (i.e. list "uio_pdrv_genirq" in /etc/modules) since the kernel can't load it automatically based on compatible-string, since that's defined as a module parameter May 15 17:58:30 a bit annoying, but oh well May 15 17:59:21 in retrospect, maybe it actually works when using compatible="uio_pdrv_genirq"; ... I should test that May 15 18:01:40 I don't see uio_pdrv_genirq in /etc/modules May 15 18:01:46 but I now have /dev/uio0 May 15 18:01:53 okay May 15 18:01:55 after adding that uio.conf and rebooting May 15 18:02:00 well... magic I guess May 15 18:02:07 :P May 15 18:02:24 so I change that in the python file to reading that instead of whatever its currently reading in there? May 15 18:03:41 I can recommend the udev rule anyway, being able to declare symlinks for devices in DT can be pretty convenient, but yeah for a quick test you can just change the path in the script to /dev/uio0 instead May 15 18:04:13 so I did that, and it pings when I set the pin high May 15 18:04:25 obviously using hardcoded uio device numbers in software would be a bad idea in general since it would have a high probability of breaking if you add more uio devices May 15 18:04:36 okay, can you suspend while the script is running? May 15 18:04:36 from high to low precisely is when it pings May 15 18:04:49 let me test thtat May 15 18:05:50 it looks like it suspends fine while that script runs May 15 18:06:48 after wakeup the script is still running May 15 18:07:27 you mean it already wakes up the system? May 15 18:07:51 nah, I just got the rtc to wake it cause I can't be bother to have to reset it every time I put it to sleep May 15 18:07:58 ah ok May 15 18:08:23 pushing that power button hurts my finger :P May 15 18:09:00 you can connect a bigger button between some P9 pin and ground May 15 18:09:15 (I don't remember the pin... P9.10 maybe? P9.09 ?) May 15 18:09:34 oh I see May 15 18:09:39 ah, P9.09 is power button May 15 18:09:42 (P9.10 is reset) May 15 18:10:15 okay so it doesn't block suspend, but requires some additional code for wakeup support May 15 18:11:29 though now that I'm thinking about avoiding race conditions I'm getting a headache... since what you really want is autosleep May 15 18:11:34 which also means wakelocks -.- May 15 18:12:02 what is exactly is 'autosleep'? May 15 18:12:32 autosleep means "sleep unless being held awake for a good reason". it's something that originally came from android May 15 18:13:09 zmatt: that does sound like something I need, cause I need to sleep unless absolutely required to be awake May 15 18:13:10 a smartphone spends most of its time in suspend May 15 18:13:24 it just wakes up when it needs to May 15 18:13:24 to save battery I imagine May 15 18:13:28 exactly May 15 18:13:35 ye I need to do the same thing May 15 18:13:41 for the same reason May 15 18:14:01 but that does require the system to track things that are keeping the system awake May 15 18:14:04 i.e. wakelocks May 15 18:14:09 so beagle supports autosleep or is it something you have to manually code? May 15 18:14:14 oh May 15 18:14:16 :( May 15 18:14:31 it's a linux kernel feature, doesn't have anything to do with beagle specifically May 15 18:14:56 any system that supports sleep supports autosleep if it's enabled in the kernel config, and I'm pretty sure it is in the standard kernels for beaglebone May 15 18:15:26 I see May 15 18:15:54 https://github.com/beagleboard/linux/blob/4.14/arch/arm/configs/bb.org_defconfig#L99-L100 May 15 18:15:57 there we go May 15 18:17:03 nice May 15 18:17:15 I wonder how gpio-keys deals with that though... because it kinda looks like it releases its wakelock after generating the input event May 15 18:17:30 but I've never really dug into autosleep May 15 18:18:44 if there's a mechanism to keep the system awake until userspace has had a chance to examine the input event and determine whether it needs to keep the system awake longer (and really there kinda *has* to be some mechanism in place for that if you think about it), then maybe you can get away with abusing gpio-keys for your purpose after all May 15 18:19:35 hmmm interesting May 15 18:20:06 min you, it is still abuse, but I won't tell anybody if you don't ;) May 15 18:20:10 *mind you May 15 18:20:37 :P May 15 18:23:05 though it's also still a viable option to patch wakeup support into uio.. I think only a couple of lines of code would be required May 15 18:23:19 and then on the userspace side you could use EPOLLWAKEUP May 15 18:23:55 I see, code required where? in the dtsi file? May 15 18:26:54 that wakelock feature is definitely interesting, insofar as to prevent race conditions because of a suspend May 15 18:28:39 zmatt: you said something earlier about needing level-triggered interrupts for this to work. Could you explain why that is? May 15 18:29:09 and is that the reason it seems to race from the gpio-key, cause thats edge-triggered May 15 18:29:17 no, in the uio kernel driver... something like https://pastebin.com/QUq03n7r May 15 18:29:18 if I'm understanding things correctly May 15 18:29:35 actually edge-triggered doesn't necessarily race May 15 18:29:49 but it's easier to get race conditions May 15 18:32:12 I'm not sure I necessarily understand why its easier to get race conditions with that May 15 18:32:16 basically if the key event were a mere pulse that "wakes up now" then you would definitely have a race condition... the system somehow needs to be kept awake (including cancelling suspend entry in progress) until the event has been handled May 15 18:32:38 oh May 15 18:33:37 oh actually I do know what mechanism does that... exactly the thing I just mentioned, EPOLLWAKEUP May 15 18:33:48 ye I was sending wake ups to that key in short periods one after the other, while putting the device to sleep when it had done its "event handling", ie ran a function called after epoll May 15 18:34:19 but did seem to get stuck on what I presume is a race May 15 18:34:31 definitely looked like it May 15 18:34:42 the benefit of a level irq is that as long as the device has a reason for needing attention, it keeps its irq asserted, which (in case of a level irq) would keep the system alive and ensure the irq handler gets called May 15 18:35:12 nice https://lwn.net/Articles/495473/ May 15 18:37:06 zmatt: so the system does not necessarily "know" when an event was handled, even after you've done whatever after the epoll has been triggered? May 15 18:38:50 I have no idea what you're asking May 15 18:40:01 as the EPOLLWAKEUP docs explain, it assumes you've handled all events returned by epoll_wait() the next time you call epoll_wait() May 15 18:40:17 if you need to keep the system awake longer than that you need to explicitly grab a wakeup May 15 18:40:20 *wakelock May 15 18:40:39 right, but what I was asking is how you tell the system that an event is handled? May 15 18:40:51 by calling epoll_wait() again May 15 18:40:51 but you've just told me that May 15 18:41:48 note that care should still be taken when using edge-triggered irqs May 15 18:42:10 for example, this pseudocode has a race-condition: https://pastebin.com/C4UnYq0t May 15 18:42:53 (assuming the device has multiple internal irqs/events that you're interested in, which is a common situation) May 15 18:43:36 actually even with a single irq enabled in the device this might still have a race condition May 15 18:43:41 definitely have multiple events, only one tho is going to cause a system wake up May 15 18:44:28 it may be a good exercise to figure out why this code is racy May 15 18:44:48 (when using edge-triggered irqs) May 15 18:44:57 ye May 15 18:45:54 (the call to device->clear_irqs() assumes the internal irqs are events/edge-triggered and need to manually cleared. if they're levels and don't require manual clear when you can ignore that call. the race condition exists in either case) May 15 18:46:21 wow this is mind-boggling stuff May 15 18:47:55 race-condition-free event handling can require a certain mental discipline... although in the end there are only a few patterns you need to know May 15 18:48:29 it definitely requires going places mentally where I haven't gone before May 15 18:48:40 I've found it very confusing to debug so far May 15 18:48:51 tho our conversation has definitely shed some light on a few things May 15 18:49:02 debugging these things can be really awful, especially since the bugs can be hard to reproduce May 15 18:49:36 good to know ahead of time, or at least before giving anything to a customer and then realizing you've written a gnarly bug May 15 18:49:45 it's definitely useful to acquire a good understanding of what is or isn't intrinsically safe than hope for the best and try to debug the mess afterwards May 15 18:50:09 s/than hope/instead of hoping/ May 15 18:50:27 that makes sense May 15 18:53:45 https://pastebin.com/ET83JCPM May 15 18:57:38 zmatt: you've described there what I've seen on the test program I've been debugging exactly May 15 18:58:16 the pin goes high and doesn't go back to low, and so the device stays asleep forever May 15 18:58:43 it missed handling an event May 15 18:58:44 also, I just realized gpio-keys makes this problem infinitely worse by debouncing the input. so even if you've ensured all irqs have been cleared, if an event comes soon enough afterwards then the edge may be filtered out May 15 18:59:00 oh man May 15 18:59:06 a good point May 15 18:59:18 I noticued however that gpio-keys also supports using an interrupt source instead of a gpio May 15 18:59:26 which would solve that problem May 15 18:59:42 kinda May 15 18:59:44 I'm not sure I understand May 15 18:59:54 whats "interrupt source" refer to here? May 15 19:00:01 the gpio edge May 15 19:00:08 same as my uio gpio-irq example May 15 19:00:15 but, no, that still sucks May 15 19:00:26 :( May 15 19:01:20 really you either want a level irq, or you should keep polling device irqs until a "key up" event has been delivered (which would require some really ugly code) May 15 19:02:03 tho polling while asleep might be a bit hard May 15 19:02:09 if I'm understanding that right May 15 19:02:15 no this is while awake May 15 19:02:24 after "irq asserted" event has been delivered May 15 19:02:51 you'd need to assume the irq is still being asserted (hence the "polling device irqs") until a key-up event (i.e. "irq deasserted") has been delivered May 15 19:03:11 so the "key up" event tells us were done? May 15 19:03:37 it tells you the irq line has been deasserted, and more importantly the gpio-keys driver has *observed* the fact that it has been deasserted May 15 19:04:14 hence you know you'll get a key-down event again (with associated system wakeup) when another irq gets asserted, hence you can safely let the system sleep May 15 19:04:22 right so that makes sure you know the state of the irq is correct or what you're expecting May 15 19:05:54 I'm guessing that whatever it writes into /dev/input/event1 is some kind of a structure with data in it, when it asserts or deasserts May 15 19:06:17 instead of polling you could also enable autorepeat to just have the gpio-keys driver fire more events if the irq line remains high. this at least allows your process to block on an event again (either key-up or repeat-key-down) hence the cpu can idle, but it does mean you'd need to grab a wakelock May 15 19:06:28 correct May 15 19:06:57 see struct input_event in /usr/include/linux/input.h May 15 19:07:59 or I guess autosleep isn't instant? if autosleep has a timeout value then you could use that instead of a wakelock May 15 19:08:11 as long as the autorepeat interval is shorter than that timeout May 15 19:08:49 I'm still leaning towards being in favor of patching wakeup support into uio and using a level irq instead :P May 15 19:09:00 :P May 15 19:09:11 do you think its just safer in general May 15 19:09:12 especially if it's really as simple as the untested four-line patch I showed earlier May 15 19:09:20 or just more suited for this particular purose May 15 19:09:25 purpose* May 15 19:09:27 more suited for this particular purpose May 15 19:09:45 I see May 15 19:09:56 gpio-keys wasn't designed for this, and while you can get it to work with gpio-keys it requires an overly complicated and messy construction May 15 19:10:10 to work without race conditions, that is May 15 19:10:23 ideally I'd like no race conditions yea :P May 15 19:13:31 with a level irq delivered via uio simply using https://pastebin.com/UyDK7X30 would be race-condition-free May 15 19:14:57 if the interrupt line from the device is still asserted at the end of this handler, then after uio_enable_irq() the irq would immediately trigger again and queue another event May 15 19:15:10 oh wow May 15 19:17:45 (uio_pdrv_genirq implicitly disables the irq whenever it fires and then queues an event to userspace and leaves it to deal with the interrupt source and reenable the irq) May 15 19:19:00 that does that uio_pdrv_genirq have documentation? or is this it: https://www.kernel.org/doc/html/v4.12/driver-api/uio-howto.html May 15 19:20:55 that is basically it, although that doc sort of assumes you're dealing with shared interrupts and therefore also have to write a small kernel driver to deal with interrupts May 15 19:21:35 although it also documents uio_pdrv_genirq May 15 19:22:06 but not how to configure one via DT May 15 19:23:52 I guess I should probably do some reading on DT, cause I'm a bit ignorant in that dept May 15 19:24:24 I mean I'm ignorant about a lot of this stuff, but gotta start somewhere :P May 15 19:24:58 still, my gpio-irq.dtsi pretty much includes everything you need May 15 19:25:23 you just need IRQ_TYPE_LEVEL_HIGH instead of IRQ_TYPE_EDGE_FALLING May 15 19:26:24 ah cool May 15 19:27:40 ugh, it's so warm here... my brain is hardly working -.- May 15 19:27:52 whats the temps where you are? May 15 19:28:06 23 ͏°C in my house atm May 15 19:28:06 its currently 25.5 C in my flat May 15 19:28:09 ough May 15 19:28:30 I'm not too hot atm, but I'm probably going for a swim anyway May 15 19:28:35 so I'll cool down a bit May 15 19:28:36 I really don't function at all at high temperatures... brain goes into thermal shutdown May 15 19:28:44 I hate hot weather May 15 19:28:49 I can't wait for winter May 15 21:58:22 Hello, excuse my question, I deleted my internal memory and I can not start, how do I fix it? May 15 21:58:42 you mean you wiped eMMC? just reflash it May 15 21:59:12 yes May 15 21:59:44 the boot light stays stuck and does nothing else May 15 21:59:50 https://beagleboard.org/latest-images here you find recommended images and instructions for reflashing May 15 22:01:42 muchas gracias ! May 15 23:18:21 Hmmm interesting how they no longer provide eMMc images because people were wiping out the eMMc flash. Which reminds me I have to update my rev B BBBs because there was a bug in them regarding booting the SD card. May 15 23:20:26 you can still find flashers here though: https://elinux.org/Beagleboard:BeagleBoneBlack_Debian May 15 23:20:52 and making a single-character change to the /boot/uEnv.txt is hopefully manageable :P May 15 23:21:25 that wiki page is also where you find console images, which is probably what you want for rev B May 15 23:22:29 Yes that is what I wanted thanks for that, because the rev B size limits, it is exactly what I need. May 15 23:41:38 Yea... May 15 23:41:50 When do the new Capes start to ship? May 15 23:42:13 The site says May 22nd but I have seen the light. May 15 23:44:10 recommendation: don't stare directly into lights May 15 23:48:16 Okay. May 15 23:48:37 zmatt: Do you know when these Capes plan to ship? May 15 23:48:47 I have no idea what you're talking about May 15 23:48:50 Okay. May 15 23:48:52 what capes? May 15 23:48:56 Look here... May 15 23:49:00 https://www.mouser.com/new/ghielectronics/ghi-electronics-beaglebone-capes/ May 15 23:49:29 I found them recently by way of Hackster.io and a person saying they were coming out. May 15 23:49:50 ... May 15 23:50:40 That fellow Mr. Kridner reported these items to me. May 15 23:51:07 I saw his post on Hackster.io. I was using that L298 motor driver and some software. May 15 23:51:09 ... May 15 23:51:15 We discussed this idea recently. May 15 23:51:36 You gave me some software to test it. May 15 23:52:15 brb...parched. May 15 23:53:57 so why are you asking me when they plan to ship when the site says they will ship the 22nd ? May 15 23:57:20 b/c May 15 23:57:31 They say that but they have none is stock. May 15 23:58:00 ehm, duh? May 15 23:58:06 if they had stock, they could dispatch right now May 15 23:58:10 Oh! May 15 23:58:26 So, they "plan" on getting them in and then shipping them out. May 15 23:58:39 but they have 200 on order and expect to be able to start dispatching them the 22nd May 15 23:58:40 Plans break. This is from a long exp. in "plans." May 15 23:58:50 I saw that... May 15 23:59:22 yes they sometimes do, but more often they're simply production times May 15 23:59:38 oh... May 16 00:00:20 I figured it was a rough est. and the plan was a specific date, May 22nd, but that this plan might have external issues. May 16 00:00:45 Ext. issues would be things like you were stating, i.e. production, mfg, and other stuff. May 16 00:00:58 ... May 16 00:01:11 Whow knows? I just know this idea, "I want two!" May 16 00:01:24 mouser buys and sells components, it's what they do. have a little bit of faith in their planning May 16 00:01:33 Fine. May 16 00:01:56 I once bought a bunch of stuff from Arrow.com and Element14.com. May 16 00:02:46 They gave me the one, two. Arrow.com gave me incompatible boards that did not work. Element14.com never sent in my order, i.e. no shipping date. They left me in the cold. May 16 00:02:49 ... May 16 00:02:57 Another issue outside of this chat, though. May 16 00:02:58 Sorry. May 16 00:04:25 zmatt: I think there are, excuse me for saying, but little men sitting in dark warehouses looking to be advantageous. May 16 00:04:26 ... May 16 00:04:28 Ha! May 16 00:08:48 Ha? May 16 01:00:45 set_ mouser has always shipped stuff. Arrow and Element14 are squirrelly at times. Mouser has a very precise method for ordering and generally if they aren't stocked yet they give you an estimate of when they will be. Mouser is owned by TTI which is a massive distributer. May 16 01:03:20 You can get your TFT LCD displays etc. they will give you tracking information information of when the order will be filled information if there is a delay information about when you were billed they will advise you when the product will get to you most likely too. May 16 01:04:15 I buy stuff from them at work on a regular basis, they can't earn money if they don't sell anything. May 16 01:04:28 Yea boy! May 16 01:04:58 GenTooMan: We shall see. I lost faith. I have to regain my faith. May 16 01:05:07 They estimate the boards will ship from GHI on may 22. May 16 01:05:14 Oh. May 16 01:05:22 Directly? May 16 01:05:28 Or to Mouser? May 16 01:05:59 That's what it says under [view delivery dates] from the factory give a week and then the time to come from there to you and well looks like end of May. May 16 01:06:53 Oh...that is what I figured. May 16 01:07:02 I will just have to wait. May 16 01:07:16 set_ all things come to those on the mailing list! May 16 01:07:48 Aw...yum, yum, yum. May 16 01:49:57 I think this is the first time I literally used the words "please never email me again" in an email reply May 16 01:51:02 -.- May 16 01:51:11 some people... May 16 01:55:40 ()----() **** ENDING LOGGING AT Wed May 16 03:00:11 2018