**** BEGIN LOGGING AT Tue Jan 29 02:59:56 2019 Jan 29 02:59:57 No offense. Jan 29 03:00:45 linux sets the reserved bit to 1 also Jan 29 03:01:01 it's maybe mandated Jan 29 03:03:57 mawk: Are you trying to interpret the communication you are receiving? Jan 29 03:04:47 no, I'm just curious Jan 29 03:04:50 Okay. Jan 29 03:04:55 Just asking. Jan 29 03:05:07 interestingly vague standard abstract :) Jan 29 03:05:41 IEEE can be very political it might be something to compete with LoRa modulation or makes LoRa modulation a standard. Jan 29 03:05:54 Politics! Jan 29 03:06:02 hmm? Jan 29 03:08:19 I keep wanting to say mawk is listening to Trump and Putin speak via private chat. Jan 29 03:09:02 "There is some BBB application person listening to us." Jan 29 03:10:01 anyhow the abstract on the IEEE standard is sufficiently vague as to what they changed. Jan 29 03:10:26 which IEEE standard, and changed relative to what? Jan 29 03:12:06 Well actually I am reading the amendment comments 802.15.4 I always had a hard time following IEEE standards, perhaps I should read them more often? Jan 29 03:12:40 "the amendment comments" ? Jan 29 03:14:32 https://ieeexplore.ieee.org/document/8362834/versions#versions <-- these as opposed to the abstract. Jan 29 03:15:35 ?? Jan 29 03:15:37 Will someone please tell me what "Standard" means to you? Jan 29 03:15:49 GenTooMan: I'm completely lost as to what you're talking about Jan 29 03:16:54 GenTooMan: note however that this page is for the ISO version of the standard (which, as far as I can tell, is the same but with different formatting, a foreword added, and a later date) Jan 29 03:18:38 https://ieeexplore.ieee.org/document/7460875 is the actual IEEE 802.15.4 Jan 29 03:19:52 set_ standard is from middle english which comes from frankish so likely Latin in origin. Meaning a standing point. Basically a point of reference is what it means to me. Jan 29 03:20:31 Right. Thank you. Like an IEEE flag for rallying to a 802.15.4 standard. Jan 29 03:21:06 zmatt Ah I wondered why ISO kept being mentioned, yet another gentooman moment. :D Jan 29 03:21:38 Are there other bodies that govern this standard? Jan 29 03:22:33 ISO variant- International Standards Organization. Jan 29 03:23:12 I thought net neutrality was to have neutral, many bodied, sights on the future of itself. Just to say, there should be more than one body. Jan 29 03:23:54 mawk? Are you still w/ it? Jan 29 03:29:02 GenTooMan jumped ship. Jan 29 03:29:13 No! Jan 29 03:30:41 Blah. Jan 29 03:34:49 with what set_ ? Jan 29 03:35:01 I disabled receiving beacon frames to stop the spam Jan 29 03:35:07 I'll do non-beacon mode anyway Jan 29 03:35:14 I have not enough days to do the full blown thing Jan 29 03:35:36 I'll just hack together a hello world with all the upper levels Jan 29 03:35:41 6LoWPAN, IPv6, UDP Jan 29 03:35:55 UDP over IPv6 is pretty trivial yeah Jan 29 03:36:56 I once made a tiny stateless UDPv6 stack in a baremetal codebase for a prototype board we made (long ago) based on a TI SoC Jan 29 03:38:28 Nothing. I thought you were getting some good info. Jan 29 03:38:55 it couldn't send unicasts other than in reply to received packets (since it didn't do neighbour discovery), but it was fine for its purpose Jan 29 03:39:06 yeah NDP is a problem Jan 29 03:39:33 even though I explicitely tell linux the short address to use with the fe80::PAN^0x02:SHORTADDR adderss Jan 29 03:39:36 well I wouldn't call it a problem, but not implementing it requires less effort than implementing it ;) Jan 29 03:39:45 but it's still doing neighbor discovery to find the address Jan 29 03:40:06 ah I don't know any of that stuff, I was simply on ethernet Jan 29 03:40:13 ah, I see Jan 29 03:40:25 well 802.15.4 has a short address thing, like a short mac address Jan 29 03:40:36 and that same address is encoded at the ipv6 level all above Jan 29 03:41:08 Well...it has been fun. I am off for now. Jan 29 03:41:15 like, a PAN ID + a short address makes an unique fe80::/64 address Jan 29 03:41:25 but linux still makes neighbor discovery to get back the short address Jan 29 03:41:51 not sure how it wouldn't Jan 29 03:42:11 it has all the required info in the fe80::/64 address Jan 29 03:42:15 you could presumably add neigbour entries manually Jan 29 03:42:33 yeah that's what I'll do Jan 29 03:48:53 but do you mean you're trying to have your userspace stack communicate with a linux stack? Jan 29 03:48:56 or? Jan 29 03:50:00 I did implement responding to neighbour discovery (obviously, otherwise I'd be unreachable), I just didn't do any of my own Jan 29 03:50:26 it's pretty trivial on ethernet though, dunno if it's more complicated on 802.15.4 Jan 29 03:53:13 I guess it is Jan 29 03:56:25 the userspace stack will communicate with the linux stack yes Jan 29 03:56:51 the neighbor discovery at 802.15.4 level I don't need to do it, I'll hardcode the addresses Jan 29 03:56:55 or I can use broadcast or whatever Jan 29 03:57:51 the userspace won't stay on linux, it's for porting to RTEMS Jan 29 14:23:57 Hi Jan 29 16:43:36 hi Jan 29 16:59:09 m Jan 29 20:29:03 Information request... Are the cape expansion headers identical between the BB Black and the BB Black Wireless ? Jan 29 20:32:34 StefG: yes Jan 29 20:33:26 the pin availability/usage on the other hand isn't Jan 29 20:33:32 yes it is Jan 29 20:33:48 maybe you're thinking of the misdesigned green-wireless Jan 29 20:33:56 ah Jan 29 20:34:07 the black and black-wireless are fully compatible Jan 29 20:34:32 so wireless is on the second usb or something like that? Jan 29 20:35:08 no, the pins that the beaglebone normally uses for ethernet include exactly all the interfaces you need for the wifi/bluetooth chipset Jan 29 20:35:20 hence the black-wireless uses those Jan 29 20:35:29 Thanks everyone ! Jan 29 20:35:42 the green-wireless was designed by idiots who left those pins not-connected and pointlessly sacrifices a whole bunch of expansion header pins instead Jan 29 20:36:40 Another one... Jan 29 20:41:39 bbl, shopping Jan 29 20:50:39 Is there a possibility to power the BBB wireless by its expansion header or we need to use the round power plug ? Jan 29 21:28:15 StefG: you can power it via the expansion header Jan 29 21:28:56 use P9.01 + P9.02 for ground, P9.05 + P9.06 for 5V Jan 29 21:30:00 good ! Thank you very much ! Jan 29 21:30:17 (two pins should be used for each because these connectors are rated for max 1A/pin) Jan 29 21:31:13 Excellent Jan 29 21:40:32 but seeed say they designed the gw in cooperation with beagle. how did that happen ? Jan 29 21:41:23 artag, zmatt: a bit of lost-in-translation. Jan 29 21:42:08 I tried to communicate the way I wanted the wireless hooked up (the way we eventually did the BeagleBone Black Wireless hookup), but they copied a lot from a wireless cape. Jan 29 21:42:17 so, they used a bunch of pins on the cape header... Jan 29 21:42:45 ah. mucking up other things that used a cape header .. Jan 29 21:42:50 I tried to explain that the other MMC interface was freed-up by disconnecting the MII from the Ethernet PHY, but they grabbed the MMC interface from the wrong pins. Jan 29 21:43:35 so, it was indeed done in cooperation, but I didn't stay on top of what they were doing enough. It isn't always easy working across 12 time zones. Jan 29 21:43:37 in other words they didn't just fail to think about the pinmux themselves but actually failed despite getting help from you Jan 29 21:44:12 that's somewhat harsh, but not totally inaccurate. they went with what they new would work. Jan 29 21:44:45 to be fair, we were trying to do the BeagleBone Black Wireless right about the same time and we had a nightmare figuring out all the tricks to get the config right... Jan 29 21:44:57 the wifi module pretty much just works or just doesn't.... Jan 29 21:45:01 does the bbg have any peculiarites or is that fairly ok ? Jan 29 21:45:15 there wasn't much of a solution to get feedback when things were going wrong. Jan 29 21:45:39 BeagleBone Green doesn't have any funkiness.... Jan 29 21:45:50 and they subsequently also failed to communicate that the pins are unusable (e.g. on the beaglebone green wireless wiki page it shows a diagram of the expansion header pins that doesn't mark the pins as in use but implies they are free) Jan 29 21:46:01 the green uses a spread-spectrum clock generator instead of the 24 MHz crystal Jan 29 21:46:12 it is just Black with HDMI removed and 2 Grove headers added. Cases can be slightly wonky due to the new position of the USB host connector. Jan 29 21:46:14 thus messing up the stability of all clocks whether you want to or not Jan 29 21:46:56 zmatt: I was not aware of this problem. Is there a note on the forum about what the clocking mucks up? Jan 29 21:47:03 oh, that's useful to know. beagle is quite interesting to time-nuts because of the fairly deterministic PRUs, but a SS clock could be irritating Jan 29 21:47:09 that's the definition of spread spectrum Jan 29 21:47:17 it means the clock isn't a stable 24 MHz Jan 29 21:47:29 I've generally recommended Green, but steered clear of Green Wireless. Jan 29 21:47:32 it's modulated in some way (the datasheet of the clock generator isn't very clear) Jan 29 21:47:48 also, if you power the green via the expansion headers, the usb device port will backfeed 5v Jan 29 21:48:00 A big part of the history of Green Wireless is it was also done in conjunction with Google. Jan 29 21:48:23 They launched their IoT platform with Green Wireless as their exclusive launch partner.... Jan 29 21:48:29 so there was a lot of time pressure. Jan 29 21:48:51 We could wait around a bit on Black Wireless, but Seeed's Green Wireless had to be done for Google IoT launch. Jan 29 21:49:19 and the result is a beaglebone variant I would warn everyone to stay clear from Jan 29 21:49:26 Which is also a big part of why it shipped with wifidog, which Robert never quite embraced and thus it never ended up on the standard images. Jan 29 21:52:28 artag: seeed presumably discovered problems with the ssc too, since the green-wireless includes it in the schematic, but has it not-placed in favor of connecting the crystal to the am335x directly Jan 29 21:53:07 which mainline u-boot target(s) support(s) the pocketbeagle? Jan 29 21:53:18 I suspect it's a bit of a dodgy thing to do to a processor. Can work if it's engineered right but can also screw up Jan 29 21:53:31 artag: especially since it is mainly used to feed PLLs Jan 29 21:53:34 currently in the Debian u-boot builds, only the beagleboneblack target is supported Jan 29 21:53:51 was curious about enabling additional targets Jan 29 21:53:52 vagrantc: pocketbeagle uses the same u-boot as every other beagle variant, u-boot will autodetect Jan 29 21:54:28 all that matters is that the pocketbeagle is included in the device variants tested for... you'd need to check whether that has hit mainline, and if so which version Jan 29 21:54:45 there are 19 am335x_* variant configurations in mainline Jan 29 21:55:12 currently, Debian only ships am335x_boneblack_defconfig Jan 29 21:56:00 artag: the ironic thing is that the individual PLLs themselves can be configured to do ssc, if you want to, thus allowing some of the benefits to be reaped without making a mess of *every* clock Jan 29 21:56:07 vagrantc: that's the one yes Jan 29 21:56:18 heh Jan 29 21:56:38 vagrantc: v2019.01 at least supports the pocketbeagle Jan 29 21:56:59 i'm pretty sure jkridner[m] managed to get pocketbeagle support into mainline u-boot, apparently tested with am335x_evm_usbspl_defconfig Jan 29 21:57:02 v2018.09 too Jan 29 21:57:19 v2018.01 does not Jan 29 21:57:23 yes, i know the support is in mainline, i'm just wondering which additional targets to use Jan 29 21:57:31 yeah, I guess it's preyy easy to make a PLL jitter. some prescalers are even intended to be run in 2 different division modes to get an intermediate divider Jan 29 21:57:34 none, am335x_boneblack_defconfig is the correct target Jan 29 21:57:48 artag: well it doesn't "jitter", it is modulated relatively slowly Jan 29 21:58:22 * vagrantc had thought rcn switched to using am335x_evm or something, since it supported more than a single board config Jan 29 21:59:52 well the am335x_boneblack_defconfig probably also boots the evm Jan 29 22:00:00 really ? that surprises me. I thought they had to change every few cycles so it didn't just create output that covers a wide range. Jan 29 22:00:22 ie a wandering carrier rather than a wide, shallow band Jan 29 22:00:49 those are the same thing as long as your measurement interval isn't too short Jan 29 22:01:34 i guess it depends by what you understand from 'relatively slowly' Jan 29 22:01:37 I mean I say "relatively slowly".. I don't recall exactly how slow it modulates, it's probably still quite fast Jan 29 22:01:40 yeah Jan 29 22:01:41 we use am335x_evm_defconfig with lots of crazy rcn-ee hacks for the Debian images. Jan 29 22:01:51 rcn-ee hacks == u-boot overlay manager Jan 29 22:02:06 you don't literally use am335x_evm_defconfig though right? Jan 29 22:02:24 I use am335x_evm_usbspl_defconfig when I play. Jan 29 22:02:37 I'd assume am335x_boneblack_defconfig is used even with the patches Jan 29 22:02:43 but maybe I'm wrong Jan 29 22:02:56 nah I'm not wrong Jan 29 22:03:13 evm defconfig includes all sorts of funky stuff that's not in rcn's u-boot Jan 29 22:03:14 * jkridner[m] explores https://github.com/RobertCNelson/Bootloader-Builder Jan 29 22:04:02 hmmm.... https://github.com/RobertCNelson/Bootloader-Builder/blob/master/patches/v2019.01/0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch hacks both Jan 29 22:05:03 grrr /opt/source/u-boot_v2018.09 on-target is not a git repo. Jan 29 22:05:20 I'm 99% sure am335x_boneblack_defconfig is used for the beaglebone images Jan 29 22:06:37 * jkridner[m] uses a u-boot on Buildroot w/ saveenv to MMC outside of partitions and is really enjoying it, including fw_saveenv/fw_printenv. Jan 29 22:08:00 see, this is something that really annoying me about seeed and the bbgw too. the beaglebone green wireless page includes all sorts of info that's just copied/included from the green, but plain wrong for the green-wireless Jan 29 22:08:07 including links to capes that aren't compatible with it Jan 29 22:08:17 *really annoys Jan 29 22:09:53 it just feels like overall laziness/carelessness at the expense of users **** ENDING LOGGING AT Wed Jan 30 02:59:57 2019