DocScrutinizer05 changed the topic of #qi-hardware to: Copyleft hardware - http://qi-hardware.com | hardware hackers join here to discuss Ben NanoNote, atben / atusb 802.15.4 wireless, and other community driven hw projects | public logging at http://en.qi-hardware.com/irclogs and http://irclog.whitequark.org/qi-hardware
arhuaco has quit [Ping timeout: 255 seconds]
pcercuei has quit [Quit: dodo]
atommann has joined #qi-hardware
woakas has quit [Read error: Connection reset by peer]
woakas has joined #qi-hardware
Ornotermes has quit [Ping timeout: 240 seconds]
Ornotermes has joined #qi-hardware
arhuaco has joined #qi-hardware
Ornotermes has quit [Ping timeout: 240 seconds]
jluis has joined #qi-hardware
wej_ has joined #qi-hardware
wej has quit [Ping timeout: 250 seconds]
<wpwrak> nicksydney: does not seem to intend to go below that AT command layer. for proper networking, you need to go far below that.
<nicksydney> wpwrak: you lost me there
<nicksydney> :)
<wpwrak> as i understand it, the critter implements TCP/IP for you and you operate at the level of TCP connections (or similar), correct ?
<nicksydney> yeah...the stack is pre-programmed in the chip and you can't change it ...so you just communicate with it via SPI or UART
<wpwrak> this means that the whole stack is frozen in the firmware. there are LOTS of functions in the stack that systems like linux implement on the host. and these are functions that change all the time, due to enhancements, bug fixes, evolving standards.
<nicksydney> right....so i guess with that price probably you will get something very simple as long as you can connect to internet i suppose....will not have the capability of linux based stack
<wpwrak> ironically, the technical capabilities must be there. underneath the firmware that implements that AT command set. so if you crack that layer, you'd have something even cheaper, but at the same time uncrippled
<nicksydney> correct me if i'm wrong so looking at how it is able to sell the chip so cheap...does this mean that we can just take a Cortex-M0 (for example) and run the wifi stack (if available) on it ?
<nicksydney> if that's true does this also means that the signal processing 2.4ghz (?) is processed by the stack too ?
<eintopf> huhu
<wpwrak> you could run some stack on a lowly ARM if you knew how to talk to the MAC / PHY layer in the chip
<wpwrak> and no, signal processing is done in hardware. you can't bit-bang 2.4 GHz ;-)
<larsc> well you rarely process the whole 2.4GHz anyway
<wpwrak> larsc: now you're adding confusing details ;-)
<eintopf> that's sdr, or?
<larsc> 2.4GHz is your carrier frequency, the signal itself has a much lower bandwidth
<nicksydney> wpwrak: "MAC / PHY layer in the chip" ... can you explain in human way please :)
<nicksydney> so let's start from signal coming in...does that being processed by the chip itself or some other different chip ?
<nicksydney> all aboard on WiFi please :)
<eintopf> it's simple if you have more mac functionality in the chip you don't can't access the phy layer. What you get is only the mac layer. If this is correct :/
<eintopf> for example I have some 802.15.4 chips with hardware address filters -> hardware address is normally mac functionality but it will decrease the work of the mcu... because the chip filters if the frame is yours or not
<eintopf> I mean the filter of hardware addresses is normally mac functionality...
Ornotermes has joined #qi-hardware
<eintopf> but it depends hardware filters are great, but sometimes FULL MAC handling sucks
<nicksydney> eintopf: MAC address you referring is this http://en.wikipedia.org/wiki/MAC_address right ?
<eintopf> yes
<eintopf> for example you ethernet card has also a mac address filter
<eintopf> if it don't have a filter you will get all packets on the phy layer and linux decide if this frame belongs to you or something others
<eintopf> this will increase the counts of interrupts and workload, etc...
<eintopf> it's normally mac functionality to check the address but sometimes this is done in your phy.
<larsc> on the other hand doing things in the MAC might prevent you from doing things you want to do because the MAC doesn't allow you to
<eintopf> Now this makes sense to do this on the chip as MAC functionality, but full mac functionality is ugly.
<nicksydney> i see...interesting... understand better now
<eintopf> cool :-) I explain something
<eintopf> on my bad english
<eintopf> s/on/with
<qi-bot> eintopf meant: "with my bad english"
<eintopf> qi-bot: thanks
<nicksydney> so normally proper 'WiFi' chip have the MAC/PHY layer in the chip firmware ...are there any other layer that are included in the WiFi chip itself ?
<eintopf> nicksydney: full mac is "doing all mac stuff on the phy and abstract a protocol"
<eintopf> nicksydney: depends :-)
<eintopf> maybe somebody has the idea to abstract a protocol for IP
<eintopf> and yes these exists -> example contiki
<eintopf> contiki is some IoT sensor operting system, you can send via tun/tap and slip IPv6 packets to it. Then contiki translate it to 802.15.4/6LoWPAN
<eintopf> more or less...
<eintopf> nicksydney: yes
<eintopf> but what I describe is to run contiki with linux
<eintopf> "The SLIP protocol is a very simple way to transmit IP packets over a serial line."
<eintopf> then you have also IP/MAC/PHY layer on the chip
<eintopf> "doing all mac stuff on the phy and abstract a protocol" -> meant s/phy/rf chip/
<eintopf> :-)
atommann has quit [Ping timeout: 260 seconds]
<nicksydney> so basically the 'WiFi Chip' will do all the heavyweight of making the packet available to OS in the format that the OS networking stack understand it ?
atommann has joined #qi-hardware
<eintopf> you mean contiki now?
<eintopf> mhh
<eintopf> If the wifi chip do more layers then you can't access these layers easily from your OS, that's what larsc said
<eintopf> and this sucks :)
<eintopf> and maybe you need some adaptation layer to adapt this in the OS layer
<eintopf> because if the chip to some MAC stuff, it's not standard and they doing they own stuff there (you are lucky if you find any documentation about that)
<eintopf> about the question "how they abstract the mac layer"
wolfspraul has joined #qi-hardware
<eintopf> but mac functionality like address filters are okay on the rf chip ;)
<eintopf> that doesn't suck
<eintopf> okay if you can't disable them, then it sucks
<eintopf> but normally you can disable them (promisocus mode, or something else)
<nicksydney> interesting thanks for that
<eintopf> you are welcome, I hope it's correct what I said
atommann has quit [Ping timeout: 245 seconds]
atommann has joined #qi-hardware
atommann has quit [Ping timeout: 260 seconds]
atommann has joined #qi-hardware
<DocScrutinizer05> !moo
<DocScrutinizer05> ((<eintopf> if it don't have a filter you will get all packets on the phy layer and linux decide if this frame belongs to you or something others)) which is then called promiscuous or monitor mode. E.G. wireshark using this, as well as tools like airodump etc do
<DocScrutinizer05> ((<eintopf> If the wifi chip do more layers then you can't access these layers easily from your OS, <eintopf> and this sucks)) depends. For embedded battery-powered it's essential, since otherwise your heavy main CPU is running all the time, doing low-level MAC stuff. Worst is when your WiFi doesn't even do address filtering, since then the CPU basically needs to handle all "noise" and nonsense that comes in over the air, to see
<DocScrutinizer05> if it's relevant or not
<DocScrutinizer05> the trick is to provide API for those lower level function in your WiFi interface to machine, so machine can decide to e.g. do address filtering on main CPU (= promiscuousmonitor mode) or let WiFi FULLMAC do that on its power economic small CPU. Same even for raw mode which e.g. gets used to do AP on N900's 1253 WiFi. Raw mode is the most low level interface to WiFi radio, basically bypassing *all* on-chip protocol layers. The radio
<DocScrutinizer05> shall send whatever raw bit data you send to it (also receive, obviously)
<DocScrutinizer05> on 1253/12xx you need some hack done by a gifted linux hacker to access raw mode in the chip
<DocScrutinizer05> since 1253 usually runs in FULLMAC mode, and the raw mode API isn't usually exposed/available
atommann has quit [Quit: Leaving]
<DocScrutinizer05> on a completely unrelated sidenote: whitepaper abour InfraRed subsystem in Neo900 -> http://talk.maemo.org/showthread.php?p=1437131#post1437131
<DocScrutinizer05> daily hacking (non-EE): we all know how to catch a fly by *slowly* moving a glass over it so it doesn't trigger the insect's optical threshold for changes in vicinity. What's supposedly new however is to use a glas from freezer, so the fly, once caught in the glass, gets stiff and lifeless during just 15 seconds ;-P
<DocScrutinizer05> very convenient since the most tricky two parts of the "catch the fly" operation are a) put a lid on the glass without letting fly escape and b) move the fly outside or kill it without it escaping and returning to your room during that
<DocScrutinizer05> a frozen fly won't escape and as well won't return into your room when you throw it out the window
uwe__ has joined #qi-hardware
uwe_ has quit [Ping timeout: 260 seconds]
jekhor has joined #qi-hardware
<DocScrutinizer51> wpwrak: (scope midi) http://maemo.cloud-7.de/share-service/20140828_001.jpg ;-D
<wpwrak> DocScrutinizer51: for convenient fly elimination, i have this: http://content.oppictures.com/Master_Images/Master_Variants/Variant_500/147907.JPG
<wpwrak> DocScrutinizer51: though flies rarely bother me. seems that they're too lazy to fly so high. mosquitos, on the other hand ..
rz2k has joined #qi-hardware
<DocScrutinizer51> eliminating flies that sit on your monitor takes special care
<wpwrak> (midi) yeah. but i don't really see it as a convenience improvement. your visual feedback would be on the pc while the signal is on the scope. and you have that control box sitting somewhere in the middle -> messy
<DocScrutinizer51> yeah, ordinarey flies fly l.ow
<DocScrutinizer51> (scope)@8md either place all three items next to each oother, or at least move that HID I linked above to where I'm currently working. Optical feedback freom PC is not the idea
uwe__ has quit [Ping timeout: 244 seconds]
<wpwrak> hmm, then you're limited to basically moving the scope's controls to new buttons. you normally can't upload images (for UI feedback) to a scope.
<wpwrak> so i don't think what you're thinking of would really work. but of course, it'll be interesting to see what you come up with ;-)
uwe_ has joined #qi-hardware
<DocScrutinizer05> moving/replicating that unbearable thousand-turns knob to a proper scratchrecord turntable and same time accelerate it properly, like a mouse, would be the easiest exercise
<DocScrutinizer05> much better solution than powertool with clutch to spin the scope's knob a 654893 times - from 0 to 80000th frame
<DocScrutinizer05> even numeric input, though admittedly without written / optical feedback to check if you did a typo, would be possible. Then let a macro spin the thousandturns exactly to the value you entered via keypad
<DocScrutinizer05> I have a *lot* of ideas how to improve the UI, and I have a pretty good idea of what's feasible and what's not
<DocScrutinizer05> store complete parameter banks, and recall them later
<DocScrutinizer05> needs pretty little feedback beyond maybe the STO06 button shortly flashing to signal it's done
<wpwrak> that 1000 turns knob's function changes with context. and the scope won't tell you in which mode the UI is. so you'd have to move the whole control to the midi device. and then you lose all intermediate feedback elements.
<DocScrutinizer51> and I'm only starting... ;)
<wpwrak> so you're getting a siglent with 1000 turns knob now ? :)
<DocScrutinizer51> well, when the API is crap then obviously you cannot tell scope "turn button C right 488 clicks"
<DocScrutinizer51> no way I get me a siglent
<DocScrutinizer51> tbh since those scopes all have a USB host jack, I'd even expect them to genuinely support kbd, mouse etc
<wpwrak> (API) "press that button for me" functions are not commonly part of the host interface. they can exist but i wouldn't count on it. e.g., rigol don't have them: http://www.tequipment.net/assets/1/26/Documents/Rigol/DS2072/ds2072_doc_5.pdf
<wpwrak> and no, they don't normally do anything sensible with keyboard and mouse. that would be overly sane ;-)
<wpwrak> so these fancy "arbitrary measurement expressions" in the rigol mean entering your formulas by turning and pushing knobs ...
<DocScrutinizer51> FSCKIT such fools
<DocScrutinizer51> that's why I asked so insistingly about the API
<wpwrak> well, what you could do with these expressions is to write a tool on the PC that lets you send them via SCPI. that's certainly an improvement. not quite what you had in mind, though.
<DocScrutinizer05> can it query *all* UI status and settings?
<wpwrak> UI ? no
<DocScrutinizer05> ohdamn!
<wpwrak> the actual measurement system, maybe
<DocScrutinizer05> that stuff is insane
<wpwrak> i mean you have the "core", samples, triggers, pass/fail, etc. and then on top you have a UI to set it up and to read out data. and you have an API to do the same
<DocScrutinizer05> I already see me REing the (*cough*) "OS" of that critter
<wpwrak> but the API isn't layered on top of the UI.
<wpwrak> you should have a look at that rigol "programming manual" (link above). that's give you an idea of what to expect
<DocScrutinizer05> I prolly only need a PEEK and POKE ;-P
<DocScrutinizer05> right, the link. On proper PC I can have a look
<wpwrak> what it does essentially allow you to do is take full control of the scope and make it do its things. but it won't help much with plugging holes in the UI. maybe you can get this to work for some operations, but i'd expect it to be messy. also because you'd be switching the scope in and out of remote mode all the some.
<wpwrak> i'm actually not even sure if you can remotely command the rigol to exit remote mode or whether you have to press a button for that.
<DocScrutinizer05> WHAT??
jekhor has quit [Ping timeout: 250 seconds]
<DocScrutinizer05> wtf *is* "remote mode"?
<wpwrak> the DS1000C* series had commands to simulate keypresses. but that doesn't seem to be available in the DS2000. dunno about DS1000Z
<DocScrutinizer05> do you say this thing doesn't accept remote commands until switched into a special mode? in which it maybe doesn't accept UI commands anymore (except the one command "leave remote mode")?
<wpwrak> when you send an SCPI command, the scope disables the UI, to prevent the user from interfering with the remote control
<wpwrak> you have to explicitly re-enable the UI after remote operation is complete
<DocScrutinizer05> ohnoes!
<wpwrak> maybe now you understand my doubts about your MIDI plan :)
<DocScrutinizer05> that's so terribly braindamaged I'd like to buy one device just to smash it into the devels' head
<DocScrutinizer05> when otoh you can terminate or commit a remote sequence via a special remote command then it makes sense
<DocScrutinizer05> what's that?:
<DocScrutinizer05> :SYSTem:SETup <setup_data>
<DocScrutinizer05> :SYSTem:SETup?
<DocScrutinizer05> Description
<DocScrutinizer05> Send the file data ofRead the file data ofthethesystemsystemsetup.
<DocScrutinizer05> setup.
<DocScrutinizer05> dacapo for pdf
<wpwrak> kinda cryptic, eh ? :)
<wpwrak> the DS1000Z can unlock the UI remotely. :SYST:LOCK 0
<DocScrutinizer05> it's not that cryptic in the pdf, just the c&p failed to keep rows separate
<wpwrak> i think the older 1000 had that, too. alas, i can't test since the communications board is fried in mine :(
<DocScrutinizer05> but what's "system setup" and might it offer some way to mess with this thing? I mean, it seems a raw blob of data
<wpwrak> (cryptic) i mean that it doesn't tell you what that command really does.
<wpwrak> yeah, exactly :)
<DocScrutinizer05> to me that sounds like a memdump of the complete config/parameter area
<DocScrutinizer05> so -> my PEEK and POKE?
<wpwrak> "these are our global variables. enjoy ! oh, and by the way, they'll be elsewhere and change their meaning in the next minor firmware revision." :)
<DocScrutinizer05> yeah, that's pretty much expected
<DocScrutinizer05> anyway, a diff will give away meaning of most bytes, no?
<DocScrutinizer05> dump systemconfig, toggle some option, dump again, diff
<wpwrak> it's at least something you can try to play with. dunno how far it goes.
<wpwrak> maybe ask on eevblog if anyone has already tried to make sense of this
<DocScrutinizer05> stuff like :SYStem:BEEPer doesn't make me smile. I'd expect a subcommand to make the thing *emit* a beep, not only to enable or disable the beeper
jekhor has joined #qi-hardware
<wpwrak> just send n invalid command and it'll beep angrily ;-)
<DocScrutinizer05> seems you can query every parameter that's listed in the API
<DocScrutinizer05> HAHAHA
<DocScrutinizer05> :-P
<wpwrak> yup, all parameters should be queriable
<DocScrutinizer05> :TIMebase:DELay:ENABle?
<DocScrutinizer05> :TIMebase:DELay:OFFSet <offset>
<DocScrutinizer05> :TIMebase:DELay:OFFSet?
<DocScrutinizer05> so yeah, mixed mode interaction, like "select left cursor on scope button press" -> "move cursor position on midi turntable" might not be possible at all
<DocScrutinizer05> but for sure something like "change parameter most recently changed, via turntable" should be completely feasible
<wpwrak> pheew ...
<DocScrutinizer05> and generally the idea is to *not* have several submenus on the luxury midi tablet, but assign a dedicated button to the 20 most needed parameters you wanna change
<wpwrak> yes, if you have a knob for every single parameter of the scope, then you can do that. but i'm not sure it's quite feasible.
<DocScrutinizer05> so instead of selecting "cursor"->"left"->"position" form a 3-level-menu-hierarchy on scope, and then use the turntable to adjust the cursor pos, I rather have a pushbutton "adjust left cursor pos" on midi tab and then it's clear what turntable does after that button got pressed and is lit
<DocScrutinizer05> the idea is exactly NOT to have a button "for every possible function" but a convenient way to adjust a dozen or two parameters that I select to my liking
<DocScrutinizer05> the exotic rarely used functions are fine on scope UI
<DocScrutinizer05> anyway, I guess it's kinda useful
<DocScrutinizer05> and the most interesting question would be: will Rigol fix bugs when you run into some?
<DocScrutinizer05> and how long does that take?
<ysionneau> win 17
uwe_ has quit [Read error: Connection reset by peer]
<hozer> anyone heard about the ESP wifi module for $5 yet
<hozer> it's got a Tensilica Xtensa architecture core in it
<ysionneau> I think this got linked here
uwe_ has joined #qi-hardware
jekhor has quit [Ping timeout: 260 seconds]
uwe__ has joined #qi-hardware
uwe_ has quit [Ping timeout: 260 seconds]
uwe__ is now known as uwe_
uwe_ has quit [Read error: Connection reset by peer]
uwe_ has joined #qi-hardware
uwe__ has joined #qi-hardware
uwe_ has quit [Ping timeout: 244 seconds]
kilae has joined #qi-hardware
jekhor has joined #qi-hardware
rz2k has quit []
kristianpaul has quit [Ping timeout: 240 seconds]
jekhor has quit [Ping timeout: 264 seconds]
jekhor has joined #qi-hardware
pcercuei has joined #qi-hardware
kilae has quit [Quit: ChatZilla 0.9.90.1 [Firefox 31.0/20140716183446]]
<wpwrak> funny. this morning, TI MCU spam. around noon. freescale community spam. now spansion design spam. i wonder if these companies realize how totally useless their "newsletters" are
wolfspraul has quit [Quit: leaving]
jluis has quit [Ping timeout: 260 seconds]
jekhor has quit [Ping timeout: 240 seconds]
jluis has joined #qi-hardware
wej_ has quit [Ping timeout: 250 seconds]
wej has joined #qi-hardware