Humpelstilzchen has quit [Ping timeout: 256 seconds]
Defiant has joined #neo900
sparetire has quit [Quit: sparetire]
dal has quit [Quit: Leaving]
Beaches_ has joined #neo900
xman has quit [Quit: Leaving.]
Beaches_ is now known as Beaches
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined #neo900
dal has joined #neo900
Pali has joined #neo900
hashcore has quit [Ping timeout: 272 seconds]
Pali has quit [Ping timeout: 240 seconds]
freemangordon_ has joined #neo900
<DocScrutinizer05>
maybe our tech affine community members want to contribute to a recent discussion Werner and I do about the HackerBus USB connection? Concerns are about mechanical stability of the 3pin header (Mill-Max 851-43-003-30-001000) as well as about signal integrity with a unterminated stub of >5mm length (from the header springs) on DP/DN. Alternatives we look into: Zebra strips (http://www.abatek.com/en/products/connectors.html) or pogopins on
<wpwrak>
(signal integrity) and EMC. after all, those headers are little antennas, and not designed with high-speed circuits in mind.
freemangordon_ has quit [Quit: Leaving.]
freemangordon_ has joined #neo900
<DocScrutinizer05>
yeah right, it might introduce some RF radiation we don't want to see
<DocScrutinizer05>
though the shielding is not all that bad: we have the BOB groundplane "on top" and even the metal case of cam module vertically parallel to them springs
<DocScrutinizer05>
anyway we should define this stuff as soon as possible, to allow designers base their layout and design of extension boards on it
tomeff has quit [Quit: tomeff]
hashcore has joined #neo900
jonsger has quit [Ping timeout: 240 seconds]
tomeff has joined #neo900
paulk-collins has joined #neo900
hashcore has quit [Ping timeout: 245 seconds]
modem_ has joined #neo900
paulk-collins has quit [Quit: Quitte]
misv_ is now known as misv
opa-ben has joined #neo900
<enyc>
i tend to find zebra connectors eventually come loose
<enyc>
need reseating somehow
<enyc>
maybe ok if boards very well supported/screwed together however
<DocScrutinizer05>
the idea with zebra is to correctly align the extension circuit PCB to the main PCB and the HB connector pads
<enyc>
and can the boards bend at all across the widnt of the zebra connector ?
<DocScrutinizer05>
hardly, it's only 3 contacts wide
<enyc>
kk and boards/connectors screwfex/fixed down either side of the mini-zebra ?
<DocScrutinizer05>
but actually proper compression resp pressing force is a problem
<enyc>
yes, exactly, thats' been my expreince of issues
<enyc>
also, i wonder how resistive the resulting contact is through that kind of strip/contact
freemangordon_ has quit [Ping timeout: 260 seconds]
<DocScrutinizer05>
enyc: we con't have any provision for screw-fixing of extpansion boards to device
<DocScrutinizer05>
the resistance is no issue for DP/DN
<enyc>
in which case i (suspect) zebra won't work reliably
<enyc>
but i've not looked into this praticular case, just saying... thats' been my expreineces =)
<DocScrutinizer05>
but probably pogopins are actually better
<enyc>
as musch as possible i'd like to see connectors' pad/tracks drawn out further across the PCB, so that damaged connectors can more easily be replaced, don't want repeat of the N900-USB socket fun
<DocScrutinizer05>
they have a way flatter distance/force curve than that zebra rubber
<DocScrutinizer05>
the USB-socket "fun" been exactly what made me start to doubt about our current planned solution involving a regular SMT-mounted connector
<DocScrutinizer05>
it's mounted to the PCB by only three pins on 3 pad of 1.5*0.7mm each
<enyc>
hehe
<DocScrutinizer05>
sounds terribly flimsy to me
<enyc>
and if its' not firmly epoxy'ed around etc...
<DocScrutinizer05>
epoxy is no option at all for series production
<enyc>
right
<enyc>
so pogopins to the rescue?
<enyc>
question being, should they be on the board, or on the expansion-board
<DocScrutinizer05>
make the "HB USB connector" vanish and the post connector on "user circuit" PCB shall be 3 pogopins
<enyc>
yes makes sense
<enyc>
i wonder how many expansion boards would use USB anyway
<DocScrutinizer05>
well, you prolly would want to short D+/- for wireless inductive charging solutions of all kinds
<enyc>
shame there isn't a 'separate' usb to that bus from that to external port
<DocScrutinizer05>
for all other projects USB is the fastest bandwidth interface by far
<DocScrutinizer05>
yeahm we only have 3 USB, and no spare
sparetire has joined #neo900
<enyc>
my intuition questions if i would have designed so the D+ D- is connected through (e.g. jumper or whatever) and said board can go 'inbetween' inbound-USB and main cpu hrrrm maybe not so useful
<DocScrutinizer05>
you can have modem USB on 2nd function of the GPIO pins on HB though
<enyc>
right
<DocScrutinizer05>
actually this is considered one of the more useful configs since it also allows access to modem raw data
<enyc>
but can't jumper the modem to connect *through* the HB, so the hackerbus device could contain a micro usb-hub on it?
<enyc>
i.e. modem + HB-device are *both* attached at same time, via a mini hub chip
<DocScrutinizer05>
well, when you disable the SoC OTG-USB on pinmux level, the external jack is free for the HB device
vakkov has quit [Ping timeout: 240 seconds]
<DocScrutinizer05>
ooh
<enyc>
kk but can't use 'both at the same time' imean
<DocScrutinizer05>
no, we don't have hubs
<enyc>
sure, but the wiring doesn't allow for the hb device to ''insert'' a hub
<DocScrutinizer05>
to use HB device you need to power down modem then, or at least disable the modem USB and only use the UART modeminterface
<enyc>
yes, which i see as an unnecessary limitation, myself
<DocScrutinizer05>
well, it's neither exactly a limitation nor unnescessary
<enyc>
i would make the jumpering, so the HB device *can* contain a hub, containing a mini hub, act as usb device, and connect the modem USB through at the same time, myself
<enyc>
(or at least consider this =), there may be a godo reason why not =) )
<enyc>
is it possible to use the full modem functioanility over serial/UART only et.c?
<DocScrutinizer05>
SoC has a USB, we connect that to modem. If you want to use it in other ways, you are free to do that, but we can't add a USB hub just to increase functionality of this rather unusual usecase
vakkov has joined #neo900
<enyc>
i don't see it as unusual to have 3g/4g modem working at the asme time as using a USB-attached hackerbus-device option of some form
<DocScrutinizer05>
you have 0R "jumpers" on modem USB, you're free to wire all 4 ends to HB-GPIO pins on 2nd level
<enyc>
aaaaaaaaaaaah as i was suggesting should be possible
<enyc>
good
<enyc>
so it would be possible for a hb-device to ''superimpose'' itself between, ok
<DocScrutinizer05>
yep
<enyc>
ok thats 'what i was thinking of but was'n clear from this provisional document
<enyc>
good
<DocScrutinizer05>
unless you run into massive signal integrity problems
<enyc>
next question, whats' the reasoning behind 0R jumpers instead of mini-mini dip-switches type things ?
<DocScrutinizer05>
USB highspeed is 480MB
<DocScrutinizer05>
even 0R are relatively huge. There's absolutely no mechanical switching component of faintly similar size
<enyc>
ok =)
<enyc>
could i suggest updating the documen with wider provisional wiring of the hackerbus and related jumpers layout e.g. modem USB you mentioned ?
<DocScrutinizer05>
many thanks for the input ans sparring :-)
<enyc>
it will take community input to work out default layout of the jumpers suggestions maybe
<DocScrutinizer05>
well, that's TBD, we don't even know how much and what exactly is feasible
<enyc>
at least try to draw it out will be helpful
<enyc>
well draw out a ''likely scenario'' and write down the main areas of uncertainty
<DocScrutinizer05>
we're not supporting a crowding of all possibly interesting signals around the HB on a huge matrix field for "jumpers". When you want to use e.g. the USB hub config you suggested, you need to run wires from HB 0R pad to distant modem-USB 0R location
<DocScrutinizer05>
those wire connections are virtually arbitrary, so we hardly can list all possible options you have with that approach
hashcore has joined #neo900
<enyc>
kk makes sense, list the major ones inclruding tose i mentioned, some near some far,
<enyc>
fully appreciate wiring is arbitrary to all manner of possibles hidden away ;p
<DocScrutinizer05>
ok, eventually I'll try to sketsch a few real life usecases
<enyc>
yes, this sort of thinking is good for getting un-fuzziness, getting an idea what sorts of things may be more useful
<DocScrutinizer05>
there's only a limited number of signals that actually make sense on HB anyway
<enyc>
list them out... =) ... what are the other major areas of uncertainty / decisions-to-be-made at the moment?
<DocScrutinizer05>
I admit an alternative USB bus would be one of the more useful usecases, since we need the external USB for quite a number of things without real alternative. E.G. video output
<enyc>
yes, and I think that its' not at all unreasonable to want USB-hackerbus-gadget-data working at the same time as lte-modem
<DocScrutinizer05>
"major areas of uncertainty"? Prolly only one: how do we get 250 more preorders
<DocScrutinizer05>
LTE modem still can work via UART. the modem has 2 interfaces
<enyc>
DocScrutinizer05: i can try to promote elsewhere when there is clear evidence/timeline/etc showing whats' needed to get project to completion, credibility that it can actually be done/completed =)
<enyc>
DocScrutinizer05: and is tat supported in typical software?
<enyc>
DocScrutinizer05: e.g. porting maemo or what-have-you ?
<DocScrutinizer05>
err, typical? we don't use 'typical' software, the modem driving software is rather tailored to fit
<enyc>
ok, so it would be written so as to support either mode or so
<DocScrutinizer05>
yes, exactly
<enyc>
is it speed-limited in UART-mode ?
<DocScrutinizer05>
yes
<Xiaoman>
Will it be possible to buy it directly, or can I only get it if I preorder?
<DocScrutinizer05>
I can't recall the actual numbers, but assume a few Mbit
<Xiaoman>
I have an aversion for preordering stuff :)
<DocScrutinizer05>
Xiaoman: the latter
<Xiaoman>
:c
<DocScrutinizer05>
Xiaoman: sorry we can't afford to build for a free market, we don't have the funds
<Xiaoman>
Understandable
<DocScrutinizer05>
we will try to produce a few dozen for such "free market"
<DocScrutinizer05>
I wouldn't count on being able to get one when you didn't preorder. When we receive hundreds of requests, we *might* be able to build a second batch
<Xiaoman>
When is the timeline for ending preorders then?
<DocScrutinizer05>
that's a pretty good question
<DocScrutinizer05>
rather: when is the timeline we have to stop the project due to lack of sufficient preorders
<DocScrutinizer05>
once we reach sufficient number, we can afford taking in a few late orders too
<enyc>
shame ther isn't a further software-configurable pin-mux on these signals to just reroute / select USB/I2c/etc paths to hackerbus... hey-ho ... engineering compromises everywhere quite normal =)
<DocScrutinizer05>
:-D yeah
<enyc>
wpwrak was on the case to make a timeline of tasks to completion iirc
<DocScrutinizer05>
Xiaoman: we're basically limited by hard-to-get components we need to source early. So far we didn't reach that point yet
<DocScrutinizer05>
yes
<enyc>
then i can (try) to solicit suggestiosns focr marketing and so on
<enyc>
but its' not credible enough (imho) without showing just how far its' come and whats' needed to get there now, imho, at least
<DocScrutinizer05>
look, the design is finalized (except extremely minor things like the before-discussed HB connector detail etc), next thing is proto_v2 building to show off a working prototype which doesn't have the right formfactor but 95+% of all technical aspects
<enyc>
excellent =)
<enyc>
so, genuinely close, but can't know exactly what issues that will show up
<DocScrutinizer05>
once we're there (which is supposed to happen during next 2 months) we're on a hold then again, waiting for the required number of preorders
<enyc>
what software needs writing to prove/test the proto_v2 enough to make a correct-formfactor-board ?
<DocScrutinizer05>
that's not much, we can test each subsystem separately on console level with simple test programs
<DocScrutinizer05>
which is also what we'll deliver as "factory image" software
<DocScrutinizer05>
bare bones devuan linux, with basically a number of shell scripts to test peripheral subsystems
<enyc>
nods! =). collate these facts together into a draft ''state of project, path to completion'' doc ?
<DocScrutinizer05>
wpwrak: ^^^^
<DocScrutinizer05>
I agree this is all not very visible to the general public
<enyc>
niggling areas of technical 5% remamining aspects, include: hackerbus and jumpering decisions (updated document suggested), what else?
<DocScrutinizer05>
a terrible expanse of rubble, made from piecemeal of info bits
<DocScrutinizer05>
the jumpering depends on real estate limitations on final formfactor PCB
<DocScrutinizer05>
nothing else comes to mind
<enyc>
ok, so add that to the notes on hackerbus, along with a few usecase considerations/examples
<enyc>
excellent =) but do look over the overall hardware diagram to see if any niggles got ''missed//stalled'' over previous months etc?
<DocScrutinizer05>
NB the jumpering is a feature for extreme hackers, those who want to solder on their device. Generic original HB specs are supposed to allow a maximum flexibility and plug&play for 3rd source expansions already
opa-ben has quit [Quit: Leaving.]
<DocScrutinizer05>
nah, we don't 'miss niggles'
<DocScrutinizer05>
:-)
<DocScrutinizer05>
there are a few tasks to get accomplished, around sourcing, once we have sufficient preorders and funds
<DocScrutinizer05>
we need to build domesheets, we need to source sufficient number of N900 mech parts
<DocScrutinizer05>
all this only makes sense after we received the minimum of preorders needed
<DocScrutinizer05>
again, the design is basically finalized
SylvieLorxu has joined #neo900
HylianSavior has quit [Ping timeout: 260 seconds]
vakkov has quit [Ping timeout: 245 seconds]
<DocScrutinizer05>
we'll give the schematics a last thorough review for any mistakes that might have crept in, before we build the proto_v2. That's standard procedure in any decent HW deleopment
<DocScrutinizer05>
development even
<DocScrutinizer05>
then we do layout, which again gets a thorough review before ordering the PCBs
<bencoh>
well, tbh even filling the project/tasks tracker to reflect project state might help with visibility to the general public
<DocScrutinizer05>
then we review the unpopulated bare PCBs after receiving them, then we populate them with components and review a last time before we apply power to bring them up
<bencoh>
it's there, just not really used ;)
<DocScrutinizer05>
we have a tasks tracker?
<bencoh>
hmm it might be hosted at goldelico, not sure
<DocScrutinizer05>
yeah, might make sense to put it to more general use
<DocScrutinizer05>
alas it's not exactly a task manager, just a bugzilla
<DocScrutinizer05>
it's incredibly hard to maintain timelines and mutual dependencies in such a thing
<enyc>
nods
<enyc>
so maybe something more resembling a document would be fine?
<DocScrutinizer05>
I'm almost tempted to try office products
<enyc>
basically use whatever-the-hell-works and can be used as source to re-fashion into marketing-for-geeks where needbe =)
<enyc>
if "it's incredibily hard" <- that doesn't work, try something else ;p
<DocScrutinizer05>
what you ask for and what actually would be pretty useful is a decent project task planner
<DocScrutinizer05>
some of the users in here offered to look into what's available and actually works, quite some time ago. Seems that never came to fruitation
<enyc>
if project is so close to completion, odes it need a full-blown planner?
<DocScrutinizer05>
yes, since so far the tasks were pretty much linear but also independently parallel to execute. Now it starts with dependencies
<DocScrutinizer05>
particularly when users want to "see something"
hashcore has quit [Ping timeout: 265 seconds]
<DocScrutinizer05>
it's all about a quite limited number of resources to get assigned to a relatively large number of mutually depening taks to accomplish
<DocScrutinizer05>
tasks even
<DocScrutinizer05>
we need to track and visualize the resources as well as the assignment to tasks and the dependencies between tasks
<DocScrutinizer05>
the tasks are relatively well defined, the dependencies are complex but almost static, what constantly changes are the resources
<DocScrutinizer05>
and to work around shortage of resources, new tasks emerge
<DocScrutinizer05>
the major next task is "reach the break even threshold for preorders" since project's success depends on that one. To accomplish that we're considering a number of methods (aka new tasks) most of which depend on completion of a proto_v2
<DocScrutinizer05>
other tasks are for example "source N900 devices" which depends on resource "funds" which depends on resource "number of preorders"
<DocScrutinizer05>
recently the resource "funds" is our most tough and scarce resource
<DocScrutinizer05>
and stuff like the now luckily killed PP issue bites huge chunks out of that resource
<DocScrutinizer05>
PP caused a damage of several k€, simply due to delay and also for lawyers etc
<DocScrutinizer05>
also due to missed preorders when people can't or didn't want to use SEPA/SWIFT
<DocScrutinizer05>
we also need somebody taking care about our web appearance. For example our frontpage could use a massive update, pimping it with slides from Werner's talk, so visitors instantly understand one of the differentiating key features of this product
opa-ben has joined #neo900
<Wizzup>
and an microblog post about the paypal issue
<DocScrutinizer05>
the more Werner and me need to take care about that stuff, the less time we can assign to actual R&D
<DocScrutinizer05>
Wizzup: good point
<DocScrutinizer05>
Wizzup: thanks!
<DocScrutinizer05>
so somebody would need to update the "News"
<DocScrutinizer05>
Neo900 UG hires! We search for a web designer (?) to draft and implement updates on our web appearance
<DocScrutinizer05>
site is Pelican based!
<DocScrutinizer05>
you need to proactively follow events in the project and consider how to appropriately update the web appearance accordingly
<DocScrutinizer05>
dos1: I edited a tiny botch, I guess it will vanish as soon as Pelican kicks in eventually. Would you be willing to give it some love so it looks and reads better, and stays?
hashcore has joined #neo900
dal has quit [Ping timeout: 256 seconds]
<wpwrak>
(task manager) "taskjuggler" (http://www.taskjuggler.org/) might be a useful tool for the usual "project management" diagrams. may take some time to develop a workflow around it, though. (i haven't used it, just had a few quick looks at it, and it seemed to be less hostile than the rest)
dal has joined #neo900
hashcore has quit [Read error: Connection reset by peer]
<wpwrak>
(in anelok, which is a much simpler project, i've chickened out on that learning curve, and i'm just writing "task cards", which are less structured and rather high-level but also give room for design considerations and such: https://gitlab.com/anelok/doc/wikis/Tasks)
jonsger has joined #neo900
<wpwrak>
(you may think of this as part of a learning process. maybe in a decade or two, i'll actually figure out how to do such things properly ;-)
<DocScrutinizer05>
moin wpwrak
<wpwrak>
quick mid-sleep break :)
vakkov has joined #neo900
<enyc>
wpwrak: i'm told something that will useyfully provide a gantt chart (properly) is highly reccomended, but no psecific taskmgr reccomendations as yet
<Kero>
gantt charts are overrated. the important information is in the dependencies, not the tasks/duration.
<Kero>
usually, when starting work for real, additional dependencies are found that delay things, even thought the work on the task itself was fairly accurate.
AndrewX192 has quit [Ping timeout: 260 seconds]
<wpwrak>
enyc: the problem i still haven't solved is how to handle the underlying data. sure, there are lots of tools to draw charts, but if they don't connect to the information the project actually needs, then they're just fancy drawing tools and you get duplicated and rapidly ageing if not diverging information.
<wpwrak>
enyc: if you look at my task cards, you'll also see that almost all the things are slightly peripheral. the main production process isn't there. that's why i don't have good way to map the dependencies, which are more important there, while the other tasks tend to be heavier on context information.
<wpwrak>
so it's all part of a long learning process. alas, not of much immediate use for neo900
mzki has joined #neo900
SylvieLorxu has quit [Remote host closed the connection]
<enyc>
wpwrak: i'm told "search OSS project planning" and there are many...
<wpwrak>
;-)
SylvieLorxu has joined #neo900
AndrewX192 has joined #neo900
<wpwrak>
drawing fancy charts isn't the problem. you could do that in xfig/inkscape/dia/whatever. the real difficulty lies in a) modeling the processes and parameters you actually need to pay attention to, and b) connecting those models with the outputs you desire, such that there's not a human in the middle acting as gateway.
<enyc>
so, whats the solution?
<wpwrak>
dunno :) you'd have to ask someone who has already completed that journey
<DocScrutinizer05>
look, we could invest weeks and months into 'funny' stuff like this - like we actually had to do for dang prestashop. The question is if it's actually beneficial to the project's success
<DocScrutinizer05>
we'll have a truckload of similar 'irrelevant' tasks to accomplish if we actually go $kickstarter to drum up the missing 300 preorders
<DocScrutinizer05>
we're only a team of two, and we're both engineers who usually steer clear by a mile of such stuff
<wpwrak>
indeed
<enyc>
=)
freemangordon_ has joined #neo900
<enyc>
the key thing is what information/presentations/otherwise is needed for credibility in other kickstarter/places i can sugges projcet, etc etc
<DocScrutinizer05>
please consider evaluating what you need to know, asking us specific questions which we always did and will continue to answer, and then compile that info into the needed form by yourself
<DocScrutinizer05>
that would actually be a huge help
<wpwrak>
btw, regarding USB: i like the idea of a separate port for HB. that would avoid most of the problems this could cause. the OMAP actually has more USB ports than we use: there is the OTG controller that goes to the USB receptacle, but there it also a 2-3 port host-only system. one of these ports is the modem, the other two are not used.
<wpwrak>
drawbacks: pin count, needs an external transceiver
<DocScrutinizer05>
2 ports iirc
<DocScrutinizer05>
one maybe not used but probably pinmuxed to another function
<DocScrutinizer05>
would be awesome if we could actually free it up
<DocScrutinizer05>
however we wpould need a PHY for it then
<wpwrak>
yup
<DocScrutinizer05>
or offer a inter-IC USB
<wpwrak>
let's see what a simple one would look like ...
<wpwrak>
interesting .. there is a 4 pin interface. apparently only for FS/LS. but then FS, might be sufficient for HB. after all, that's still fast enough even for (compressed) HDTV video :)
<DocScrutinizer05>
is it?
<DocScrutinizer05>
webcam?
<DocScrutinizer05>
I think FS is no significant improvement over UART
vakkov has quit [Ping timeout: 256 seconds]
<DocScrutinizer05>
the idea of USB on HB was explicitly to have a high bandwidth interface
<wpwrak>
720p with H.264 should be about 8-9 Mbps.
<DocScrutinizer05>
well, not relevant for e.g. adding storage
<DocScrutinizer05>
also who would add a H.264 codec to a extension circuit
<wpwrak>
yes, for storage you need more than FS. not sure how relevant a use case that would be, though. i mean, we already have a bunch of other storage options.
<DocScrutinizer05>
ask musicians, they will insist in FS being even too slow for decent audio cards ;-)
<wpwrak>
ah, those delay freaks :)
<DocScrutinizer05>
anyway I'm not considering to provide a FS-only USB to HB, we covered all possible usecases for that by UART already
<wpwrak>
so a full ULPI is 8-12 signals, it seems. (according to the TRM) what's the difference ?
<DocScrutinizer05>
parallel databus
<DocScrutinizer05>
serial isn't fast enough for HS
hashcore has joined #neo900
<wpwrak>
no, i mean between 8 and 12. seems that both are HS
<DocScrutinizer05>
yeah
<DocScrutinizer05>
I tink it's the bus width nevertheless
<DocScrutinizer05>
4 bit or 8 bit
tomeff has quit [Quit: tomeff]
<wpwrak>
so there is nothing else that's different ? just 4 more/less bus lines ?
<wpwrak>
seems odd
<DocScrutinizer05>
wild guessing, based on some "I seem to have read..."
<wpwrak>
ah, DDR vs. SDR
<DocScrutinizer05>
:nod:
<wpwrak>
and TI say "12-pin/8-bit data SDR". @#%$^!
<DocScrutinizer05>
lol
<wpwrak>
oh, wait. 12, of which 8 are data.
<DocScrutinizer05>
yeah, sure. makes sense
<wpwrak>
okay, so it's 12 signals then, no matter what
<DocScrutinizer05>
err nope, with DDR it's only 8, with 4 bit bus, no?
<wpwrak>
the critter (OMAP) also supports DDR for ULPI TTL (directly to device, without transceiver), but that somehow seems to be different from ULPI to a transceiver.
<DocScrutinizer05>
with SDR it's 12, with 8 bit bus, for same net BW
<DocScrutinizer05>
TTL is what I incorrectly named "Inter-IC"
<wpwrak>
yes, SDR: 8+4, DDR: 4+4.
freemangordon_ has quit [Quit: Leaving.]
<DocScrutinizer05>
I dunno if TTL is different to regular ULPI. Just the register set is most likely differently defined
hashcore has quit [Ping timeout: 250 seconds]
<DocScrutinizer05>
for TTL a lot of PHY specific register settings make no sense
<wpwrak>
no idea, really. i know that many talented and highly motivated engineers put a lot of effort into complexifying that UPLI interface. so i wouldn't be surprised of there was something that would prevent TTL from properly talking to a transceiver.
<DocScrutinizer05>
if only the P*S8 had TTL as an option
<DocScrutinizer05>
TTL won't talk properly to transceiver
<DocScrutinizer05>
the "command set" is different
<DocScrutinizer05>
a non-TTL generic ULPI however should *probably* be capable of TTL
<DocScrutinizer05>
I _guess_ TTL is simply a subset of generic ULPI command set
<DocScrutinizer05>
plus a few simplified state engine transitions I guess
<wpwrak>
and the OMAP generally seems to be "anti-modular". i.e., i often see modes of operation that don't allow part of the subsystem to be more A and the rest mode B. so i wouldn't expect this to be "hackable".
<wpwrak>
though that's just conjecture, of course
<wpwrak>
s/more/mode/
<DocScrutinizer05>
for example think of VBUS which is not even existing in a TTL domain
<wpwrak>
anyway, the easiest choice would then probably be to add another USB3322C since we already have one for the modem, and we need the same feature set anyway
xes has quit [Ping timeout: 256 seconds]
<DocScrutinizer05>
do we actually have a spare HS USB ?
<wpwrak>
(vbus) but that's not on ULPI anyway.
<DocScrutinizer05>
it is
<DocScrutinizer05>
aiui
<DocScrutinizer05>
even ID is on ULPI
<wpwrak>
well, we should have a port. whether we have the pins, nobody knows (yet)
<DocScrutinizer05>
the PHY sends an "IRQ" when e.g. ID gets grounded
<wpwrak>
i mean "no VBUS signal on the physical interface"
freemangordon_ has joined #neo900
<DocScrutinizer05>
no, since the physical interface is a bus sending logical data in form of commands, responses, and interrupts
<DocScrutinizer05>
and the command set is specified in ULPI spec
<wpwrak>
yup, so there seems to be nothing that would inherently prevent an interface that, with identical wires, does SDR-PHY, SDR-TTL and DDR-TTL, from also doing DDR-PHY. except if the OMAP's anti-modularity prevents it. but since we don't know, we have to assume that it does.
<wpwrak>
which brings us back to the USB3322 and the need to free 12 pins ...
<DocScrutinizer05>
you know how e.g. N810 entered hostmode by software control? the CPU sends a command via MUSB core and ULPI to PHY, so the PHY emulates the ID-pin grounding and sends an interupt via ULPI to MUSB core so the state machine in MUSB goes hostmode
<DocScrutinizer05>
1707 doesn't support that ID emulation
<wpwrak>
someone must have been watching the jfk assassination, then ran wild with the magic bullet theory ...
<DocScrutinizer05>
yeah
freemangordon_ has quit [Client Quit]
<DocScrutinizer05>
I even know who's the employer of that guy: Mentor Graphics
paulk-collins has joined #neo900
<DocScrutinizer05>
maybe now you understand how much fun was development of H-E-N
<DocScrutinizer05>
...and why Nokia was absolutely sure hostmode wasn't feasible on N900 ;-D
xes has joined #neo900
vakkov has joined #neo900
<wpwrak>
hmm, heavy multiplexing on those pins. but let's see ...
Kabouik has quit [Quit: No Ping reply in 180 seconds.]
<DocScrutinizer05>
there's a nice utility called pinmux
Kabouik has joined #neo900
<wpwrak>
you've been talking about that monster for a very long time. i gather that it must be pretty intimidating :) but i think there's a much easier way, without going all gooey. that is, if the pin data from the PDF is reasonably parseable.
Pali has joined #neo900
<DocScrutinizer05>
would be worthwhile. Pinmux is quite a PITA starting with the fact it needs windows to run
<DocScrutinizer05>
there's a webapp version that doesn't support OMAP3
<wpwrak>
how useful ;-)
<wpwrak>
also, webapp sounds great. in the cloud's longevity we trust :)
<bencoh>
krkrkr
<wpwrak>
SaaS was yesterday. now it's YoYWaaS (Years of Your Work as a Service)
<DocScrutinizer05>
WYGIWYD, what you get is what you deserve
<wpwrak>
indeed. i always smile when i read about some cloud service dropping off the interwebs without prior warning, and all agony among its former users :)
<wpwrak>
PDF structure looks encouraging. pdftotext produces an interesting-looking mess with default settings, but with -layout, this looks parseable. let's find out if it is ...
<bencoh>
human-parsable, kindof
<DocScrutinizer05>
lemme check if I could export something meaningful from pinmux
<DocScrutinizer05>
later, have to run for shopping now
tomeff has joined #neo900
<wpwrak>
bencoh: i'm more thinking of a script that reads all the multiplexing data. then an allocation map could be run against this. allocation map generated from text file passed through cpp, so moving things around (= renaming) is easy.
<DocScrutinizer05>
oh right, pinmux creates C source output
SylvieLorxu has quit [Remote host closed the connection]
<wpwrak>
and of course table positions dance around. sigh. when will those computers finally understand that resistance is futile.
SylvieLorxu has joined #neo900
<DocScrutinizer05>
only after you fitted them with 0R only
xes_ has joined #neo900
xes has quit [Ping timeout: 245 seconds]
<wpwrak>
there's an idea. dunk the whole critter into a bath of molten copper. greatly simplifies specs and subsequent testing :)
<MonkeyofDoom>
molten copper is a room-temp superconductor ;)
vakkov has quit [Ping timeout: 250 seconds]
<DocScrutinizer51>
nice one :D
mzki has quit [Quit: leaving]
illwieckz_ has joined #neo900
modem_ has quit [Ping timeout: 240 seconds]
illwieckz has quit [Ping timeout: 240 seconds]
modem_ has joined #neo900
JesperH has joined #neo900
<JesperH>
I've noticed a connection issue with neo900.org. I can connect fine with ipv4, but on ipv6 I get timeout. Perhaps a firewall issue? Or perhaps ipv6 isn't enabled anymore, but someone forgot to update the dns records? :)
<JesperH>
Only noticed it because my rss reader (rss2email) keeps telling me that it can't connect. Works fine in Firefox, oddly
<DocScrutinizer05>
strange
<DocScrutinizer05>
maybe dos1 can look into it
<DocScrutinizer05>
thanks for reporting
saper has quit [Read error: Connection reset by peer]
saper has joined #neo900
* DocScrutinizer05
afk
paulk-collins has quit [Ping timeout: 260 seconds]
<dos1>
hmm... no idea, from server side it looks fine
<dos1>
I cannot even ping it via ipv6, it could be something on hetzner side
<dos1>
newbie works, rust doesn't have ipv6 connectivity at all atm
<dos1>
but it should have, it's configured and IP matches what's pointed to by the domain
<DocScrutinizer51>
nevermind then
<DocScrutinizer51>
nevermind then
<DocScrutinizer51>
hetzner infra issue
<DocScrutinizer51>
maybe try a traceroute/mtr from rust via ipv6 interface to arbit dest
<JesperH>
Thanks for looking into it. Will be happy to help troubleshooting, if there's anything I can do
Kabouik has quit [Quit: No Ping reply in 180 seconds.]
Kabouik has joined #neo900
<edwin>
fwiw traceroute6 stops here for me:
<edwin>
5 hetzner.interxionfra4.nlsix.net (2001:7f8:13::a502:4940:1) 13.650 ms 14.228 ms core22.hetzner.de (2a01:4f8:0:3::11) 17.983 ms
<edwin>
6 hos-tr3.ms-ex3k1.rz16.hetzner.de (2a01:4f8:0:d1:3:d:16:1) 21.501 ms core22.hetzner.de (2a01:4f8:0:3::11) 18.841 ms core21.hetzner.de (2a01:4f8:0:3::9) 19.282 ms
<edwin>
7 * hos-tr4.ms-ex3k1.rz16.hetzner.de (2a01:4f8:0:d1:4:d:16:1) 19.927 ms 19.902 ms
xman has joined #neo900
vakkov has joined #neo900
vakkov has quit [Ping timeout: 240 seconds]
fling has quit [Ping timeout: 240 seconds]
Pali has quit [Ping timeout: 240 seconds]
Pali has joined #neo900
Kabouik has quit [Quit: No Ping reply in 180 seconds.]
Kabouik has joined #neo900
Kabouik_ has joined #neo900
vakkov has joined #neo900
Kabouik_ has quit [Quit: No Ping reply in 180 seconds.]
Kabouik_ has joined #neo900
Defiant has quit [Ping timeout: 240 seconds]
arcean has joined #neo900
Defiant has joined #neo900
hashcore has joined #neo900
Kabouik has quit [Ping timeout: 240 seconds]
hashcore has quit [Ping timeout: 240 seconds]
Kabouik_ has quit [Quit: No Ping reply in 180 seconds.]
Kabouik has joined #neo900
Kabouik has quit [Quit: No Ping reply in 180 seconds.]
Kabouik has joined #neo900
paulk-collins has quit [Ping timeout: 256 seconds]