<enyc>
DocScrutinizer05: ooh RTS CTS i see on header =)
<DocScrutinizer05>
so?
<enyc>
DocScrutinizer05: they often seem to be omitted, i guess thats' more ok on just 'consoles' rather than 'reliable ttl serial bus' ??
<DocScrutinizer05>
yes, you want hw-flowcontrol
<DocScrutinizer05>
plus those RTS/CTS have very special function when UART in IrDA mode
<enyc>
i just rember all the mistakes to be made getting serial lines the wrong way round epsecially RX TX markings
<enyc>
DocScrutinizer05: interesting, somethin todo with activating the transmitter ?
FIQ has joined #neo900
<DocScrutinizer05>
not exactly. The SoC UART sends IrDA data on those lines instead of TX(RX) in IrDA mode
FIQ has quit [Changing host]
FIQ has joined #neo900
<DocScrutinizer05>
weird stuff
<enyc>
interisitng
<DocScrutinizer05>
see our IR whitepaper
<enyc>
so like, does some of the irda mod/demod at the host end, rather than separately in irda module ?
<DocScrutinizer05>
yes, it does all the 'codec' stuff in UART
<DocScrutinizer05>
except carrier
<DocScrutinizer05>
see our IR whitepaper
freemangordon_ has joined #neo900
vakkov has quit [Ping timeout: 240 seconds]
<enyc>
i recall there were lots of decisions about mounting the tx/rx inside the case small window etc.
<DocScrutinizer05>
yes
<DocScrutinizer05>
those are minor critical decisions though, as long as it all fits
<DocScrutinizer05>
anyway this is UART3 and you got boot console on it, IrDA, and even modem UART probably
<DocScrutinizer05>
so it's rather universal
<DocScrutinizer05>
when you switch off the SoC UART, you can take over control over the IR transceiver, and if we manage to put modem on same UART, you even can talk to modem directly from user circuit, or you listen to either IR or modem talking to SoC
<DocScrutinizer05>
theoreticall even modem could talk to IR
<Wizzup>
next headline: nsa loves it when you use neo900?
<DocScrutinizer05>
huh?
<Wizzup>
the tl;dr is "the nsa loves it when you use technology that they can identify and find important"
<Wizzup>
(nothing new there)
<DocScrutinizer05>
well, that's well known and shouldn't stop you from using pgp, rather the contrary
<Wizzup>
I know
<Wizzup>
hence my comment
<DocScrutinizer05>
the really critical stuff gets sent steganographed into cat photos anyway
<DocScrutinizer05>
;-)
<DocScrutinizer05>
however note this is a sw-domain consideration and not really applicable to Neo900 which just provides a clean hw platform for you to do whatever you like on it, be it hate comments on fackebook or pgp encrypted mail or atomic bomb construction plans hidden in cat photos
<DocScrutinizer05>
you just can be more sure about whatever you do, it's not compromised by malware hidden deep inside your hardware
<DocScrutinizer05>
use pgp on a regular smartphone and NSA actually cheers because they easily can intercept all you type *before* you even started pgp to encrypt it
<DocScrutinizer05>
NB NSA also could spy on pgp content plaintext on receiver side, though. after decryption. if the receiver side platform is not secure
<bencoh>
d000med
vakkov has joined #neo900
<DocScrutinizer05>
nah, you just need to adhere to strict rules. When you are not blessed with owning a inherently safe device like Neo900, you're supposed to move the encrypted stuff to a offline system, via USB stick for example. And that offline system can safely decrypt then, as long as you make sure you *NEVER* connect the device to internet or expose to any other external access (WLAN, BT...)
freemangordon_ has quit [Ping timeout: 240 seconds]
tomeff has quit [Quit: tomeff]
SylvieLorxu_ has joined #neo900
rootman has quit [Quit: Lost terminal]
lobito has quit [Quit: Leaving.]
arossdotme-planb has joined #neo900
arossdotme has quit [Ping timeout: 264 seconds]
SylvieLorxu has quit [Read error: Connection reset by peer]
<wpwrak>
(tentative) still need to coordinate this with nikolaus. (partial) there are still some ~70 gpios that need assigning. but that's for later.
<wpwrak>
and just in case you want to use the information from that infamous Table 2-1 from the data sheet in your own DM3730 project, here's a machine-readable version: https://neo900.org/git/?p=misc;a=blob;f=pinmux/cbp.csv
<DocScrutinizer05>
you're awesome
Pali has quit [Ping timeout: 240 seconds]
jonsger has joined #neo900
<wpwrak>
https://neo900.org/git/?p=misc;a=blob;f=pinmux/Makefile#l60 explains the manual changes after extracting that table from the PDF. most of them just fix things where pdftotext guessed wrong.
<DocScrutinizer05>
hey fans! I just realize our hackerbus VBATT_RAW should probably connect *after* internal battery gauge, so the internal bq27200 or whatever will correctly estimate remaining charge in primary device battery, even wehn (dis)charging the battery via VBATT_RAW
<DocScrutinizer05>
if you simply want to beef up battery capacity by parallel connection of a second cell to VBATT_RAW, you simply can apply a multiplier factor to the capacity metered in primary cell. If for example you connect a second BL-5J to VBATT_RAW then that second cell will have same amount of remaining charge like main battery, so you multiply by factor 2
tomeff has joined #neo900
<DocScrutinizer05>
when you for example connect a inductive charger to VBATT_RAW, the battery gauge will correctly track the charge of main battery
modem has quit [Ping timeout: 264 seconds]
<DocScrutinizer05>
if you want a huuuge aux battery with sophisticated management, you use a I2C-controlled charger chip powered by e.g. VBUS_OTG, to charge the huge cell. And you use a step-down converter to feed no more than a reasonable charge current (1C, aka 1300mA) to VBATT_RAW as soon as VBATT_SWITCHED is powered ( = device is on) and VBATT_RAW is lower voltage than aux cell
<DocScrutinizer05>
or you simply don't use (do not insert) the main battery at all and simply operate the device from your new huge cell only, replacing the internal bq27200 batt gauge query by a query to a more appropriate batt gauge - there might even be a built-in gauge chip that doesn't need a series shunt resistor but simply uses impedance metering via cell plus and minus (2 wire), which works for cells externally attached via VBATT_RAW, as well
<DocScrutinizer05>
comments solicited
modem has joined #neo900
paulk-collins has quit [Quit: Quitte]
l_bratch has quit [Quit: Leaving]
jonsger1 has joined #neo900
jonsger has quit [Ping timeout: 250 seconds]
jonsger1 is now known as jonsger
raoulzecat has joined #neo900
Kabouik has joined #neo900
Kabouik_ has quit [Ping timeout: 264 seconds]
l_bratch has joined #neo900
jonwil has joined #neo900
SylvieLorxu_ has joined #neo900
SylvieLorxu has quit [Read error: Connection reset by peer]
freemangordon has quit [Remote host closed the connection]
freemangordon has joined #neo900
freemangordon has quit [Remote host closed the connection]
freemangordon has joined #neo900
l_bratch has quit [Read error: Connection reset by peer]
l_bratch has joined #neo900
<enyc>
DocScrutinizer05: what i would say is strongly agree with ''think about use cases'' in everything as you are sensibly doing
<enyc>
DocScrutinizer05: i'm not enough of a battery-geek to answer too much more, but user-wise i agree ientirely with ' make sure huuuuuge bolt-on batteries can be accomodated'
<enyc>
DocScrutinizer05: *possibly* including means to hack/connect usb-power-banks in some robust-enough-manner rather than necessarially using the most-effiient VBAT type connectivity
<enyc>
DocScrutinizer05: errr and not pulggoing via microsub no the side
<wpwrak>
i must say that i'm a bit sceptical about having all those power options on HB. they're pretty inconvenient there, because the small connectors are not designed for high current, so we need multiple pins for each rail.
<enyc>
kk =)
<enyc>
fair points too =)
<enyc>
what currents are you talking about? what counts as 'high' etc etc ?
<wpwrak>
but the bigger issue is that by interfacing to HB, you need to make an adapter board, then attach this to your battery pack (or whatever), stabilize the whole think mechanically, etc. this is the kind of scenario where i'd probably prefer a cable over a connector, and an HB adapter board would only add an extra step.
<DocScrutinizer05>
???
<DocScrutinizer05>
you're aware the HB *is* a connector?
<Oksana>
Stabilise mechanically : 3D-print your own battery cover. I think that if you need adapter board between HB-and-whatever, then you are trying to think about complicated scenarios, like "a I2C-controlled charger chip powered by e.g. VBUS_OTG, to charge the huge cell. And you use a step-down converter to feed no more than a reasonable charge current (1C, aka 1300mA) to VBATT_RAW as soon as...
<wpwrak>
yes, but not a very nice one, for power.
<Oksana>
...VBATT_SWITCHED is powered ( = device is on) and VBATT_RAW is lower voltage than aux cell"
<DocScrutinizer05>
well, we can't afford a better one, and I think it's sufficient
<wpwrak>
(elaborate) VBAT_RAW has two contacts on HB. and things need even more connections underneath (BOB-LOWER), where the yet-to-be-specified connector is likely to have a lower current rating
<DocScrutinizer05>
so?
<DocScrutinizer05>
we have the current rating in GB whitepaper. We will make sure the current isn't going higher than what those connectors can handle, by implementig a polyfuse there
<wpwrak>
it's a pretty significant effort to get these power rails up to HB. and there you then either have a messy connector or an adapter board. power just doesn't seem too good a fit for HB.
<DocScrutinizer05>
meh
<DocScrutinizer05>
the HB spec is more or less finalized. I don't see the use of starting a discussion about such stuff again
<wpwrak>
actually, we don't have an explicit current rating. you vetoed that :) what we have is a reference to the fuse
<DocScrutinizer05>
yes, and that fuse will get dimensioned to match the specs of the connector. Where's the problem?
<DocScrutinizer05>
why are we discussing this again?
<DocScrutinizer05>
and >>the small connectors are not designed for high current, so we need multiple pins for each rail<< implies that there will be high current, which is not a requirement
<wpwrak>
we do allow charging, though
<DocScrutinizer05>
the only situation where current really matters would be the usecase where you have aux battery but no main battery inserted. Then the aux battery needs to drive modem via VBATT_RAW. This might or might not fly, depending on what the connectors actually will be able to cope with
<DocScrutinizer05>
a problem might be if user wants to use VBUS to power a charger on user circuit
<DocScrutinizer05>
the micro USB receptacle is rated up to 2A, however the connector most certainly can't cope with that much
<DocScrutinizer05>
so if you want to add a 4Ah battery there, you will want to also add a charging plug of sorts to your extended battery cover
<wpwrak>
thinking of current rating, hb.pdf should probably show where that fuse is located, not just describe in text. to avoid confusion. one for the to do list ...
<DocScrutinizer05>
hm?
<DocScrutinizer05>
why does it matter where it's located?
<wpwrak>
i mean electrically, not physically. just a documentation issue, nothing that affects the design
<DocScrutinizer05>
the fuse is "in the wire"
<DocScrutinizer05>
"directly behind" the connector
<wpwrak>
between connector and battery; not part of VBAT_SWITCHED
<DocScrutinizer05>
well, actually main battery has its own fuse, and the VBATT_RAW connects to VBAT rail _after_ that main batt fuse
<DocScrutinizer05>
and VBATT_SWITCHED is a completely different story
ndnihil has joined #neo900
<DocScrutinizer05>
the latter is not supposed to provide more than a maybe 100mA
<DocScrutinizer05>
it's switched by same FET switch like VBATT of things like WLAN module etc
<wpwrak>
how about including such indicative ratings as "design objectives" or such ? to make at least sure everyone has roughly the same idea of what's going on there
<DocScrutinizer05>
sure, why not
<DocScrutinizer05>
much of it will be implementation-defined though
<DocScrutinizer05>
prolly the connector is the limiting factor usually
<wpwrak>
hmm, probably the system rail. hit it too hard and bad things happen even before the connector reaches melting point
<DocScrutinizer05>
FET switch for example might have integrated overcurrent protection, but that's not specified yet and depends on implementation. FETs can handle rather huge currents nowadays
<wpwrak>
(fet) so i thought when i implemented my little fet + silo + comparator voltage regulator ;-))
<wpwrak>
that fet was actually a highly reliable fuse. burnt each time i shorted the output
<DocScrutinizer05>
hehe
<DocScrutinizer05>
yeah, we need to make sure this doesn't happen, either by integrated overcurrent protection or by dimensioning stuff in a way so a resetable fuse (of battery) triggers before magic blue smoke escapes from FET
<wpwrak>
besides that, the regulator worked great. i guess to save the fet, i'd have to have some reasonably quick on-time limiting. but i couldn't find any nice function block that would do that for me in hardware.
<wpwrak>
(that was with a kinetis, like the one we have for NFC. of course, doing very different things there)
<DocScrutinizer05>
I recall that thing
<DocScrutinizer05>
do you happen to recall what's the actuall curent rating of that 1.27mm female TH connector?
<wpwrak>
the one we won't use ?
<DocScrutinizer05>
no, the main one
<DocScrutinizer05>
the 20pin err 20hole
<wpwrak>
851-43-003-30-001000 is 1 A
<wpwrak>
err, M50-3151042
<DocScrutinizer05>
which sounds just OKish for all of the above
<wpwrak>
the 851 .. hmm ....
<wpwrak>
anyway, M50 is the one we're interested in there. the 851 was USB
<wpwrak>
or rather, will have been. it's not deleted just yet
mzki has quit [Quit: leaving]
vakkov has quit [Ping timeout: 256 seconds]
SylvieLorxu_ has quit [Remote host closed the connection]
jonsger has quit [Quit: jonsger]
raoulzecat has quit [Quit: byebye]
tomeff has quit [Quit: tomeff]
jonsger has joined #neo900
<wpwrak>
USB OTG pogo is rated at 2 A. we're so "POD Ready" (Power Over Data)