NIN101 has quit [Quit: No Ping reply in 180 seconds.]
Svetlana has joined #neo900
MonkeyofDoom has joined #neo900
arcean has quit [Quit: Konversation terminated!]
obsed has joined #neo900
Oxyd76 has quit [Ping timeout: 246 seconds]
Oxyd76 has joined #neo900
Pali has quit [Remote host closed the connection]
nox- has quit [Quit: Leaving]
<jonwil>
freemangordon: pulseaudio-module-nokia-music 90% cloned (just one function that needs cloning and one that needs verification)
<jonwil>
and yes it compiles :)
<jonwil>
so thats 6 functions left (3 in drc.c, 1 in eap_qmf_stereo_int32.c and 2 in module-nokia.music.c) and we will totally have libnokia-common, module-nokia-music and module-nokia-record
<jonwil>
leaving only module-nokia-voice and its nightmare mess of code (all the code hidden behind the generic description "audio enhancement package" in particular scares me)
<jonwil>
all that armcc code that is
Oxyd76 has quit [Remote host closed the connection]
Oxyd76 has joined #neo900
Oxyd76 has quit [Ping timeout: 246 seconds]
Oxyd76 has joined #neo900
<jonwil>
"DocScrutinizer05in short: pnatd does AT->ISI, we need ISI->AT" We dont, what we need is to replace the cellular services daemon and its plugins with a new daemon that talks AT commands to the gemalto modem on the bottom and talks the same dbus interfaces as the cellular services daemon on the top
<jonwil>
Reverse engieering more of those dbus interfaces is something I want to do at some point
<jonwil>
but right now I am focused on audio :P
svree4 has joined #neo900
<DocScrutinizer05>
jonwil: about right, yes
<DocScrutinizer05>
that's the radical approach
<DocScrutinizer05>
I'm not completely sure about one single app: network monitor. It _might_ fail, since it _might_ depend on talking ISI to modem. Anyway it will fail either way, since the interion modem prolly doesn't supply the same data(-structures) like BB5/ISI
* DocScrutinizer05
planned to do this since ages...
<DocScrutinizer05>
jonwil: netmon seems to provide a nice convenient collection of dbus signals our FOSS-cmd must support/provide
<DocScrutinizer05>
not comprehensive but nevertheless a good starting point
paulk-aldrin has joined #neo900
<DocScrutinizer05>
s/cmd/csd/
mvaenskae has joined #neo900
<DocScrutinizer05>
the internal logic is easily copied from FSO fsogsmd or whatever it's called. Please ask dos1 regarding that
<freemangordon>
jonwil: great!
<DocScrutinizer05>
re AEP, I suggest to first get a working frame that implements a module that does nothing to audio but just feeds data through from input to output. Possibly calling the top level AEP function dumy that just returns the data unchanged
<DocScrutinizer05>
all AEP is nice to have but not mandatory for operation of the Neo900 audio
<DocScrutinizer05>
as the name suggests it just *enhances* the audio quality. We are happy with an "inferior" audio quality to start with, particularly since cinterion module does all the AEP internally already
<DocScrutinizer05>
of course that doesn't help for SIP etc, but that's a goal for a future effort
Humpelstilzchen has joined #neo900
<freemangordon>
DocScrutinizer05: I think in that aep lives all the stuff like AEC, sideband, etc
<freemangordon>
also, big part of the -voice module are glibc wrappers and libcmtspeechdata
<freemangordon>
the former we don;t need, the latter we already have
<freemangordon>
I guess AEP is about the size of EAP
<freemangordon>
EAP took us how much? 3 week? a month?
<freemangordon>
not that bad
<freemangordon>
*weeks
<freemangordon>
DocScrutinizer05: do we have an option to *not* use modem's built-in audio processing?
<jonwil>
Lets start by getting -record and -music finished and working :)
<jonwil>
and trust me, I can tell you aep is bigger than eap
<jonwil>
aep module on harm is 167kb, drc on harm is only 56kb
<jonwil>
so its about 3x bigger
<jonwil>
eq module is 40kb
<jonwil>
xprot is 32kb
<jonwil>
obviously that may not reflect Fremantle
<jonwil>
but its an indication of the amount of data we are dealing with
<DocScrutinizer05>
freemangordon: yes, we can select audio profiles in modem. different audio profiles do different kind and amount of processing. some parameters are adjustable by user, others only by request to Cinterion to tweak them in firmware (aka "hardcoded")
<DocScrutinizer05>
AEC which probably is a part of AEP is for sure quite complex and large
<DocScrutinizer05>
particularly AEC is not really needed and even deprecated for our modem, we got a better AEC and Noise Gate built in to modem, which actually even knows to use two mics to distinguish between wanted voice and unwanted background noise in a much smarter more sophisticated way
<freemangordon>
I am sure gemalto's modem will do it better, the point is about maintaining the same set of modules for both N and Neo
<jonwil>
We can make the bits we dont want on Neo900 configurable via the .parameters files
<jonwil>
There is already different parameters for N900 and N9
<jonwil>
no reason we cant have N900 and Neo900 with different flags
<DocScrutinizer05>
that's why I said we _need_ all the policy stuff REed and documented/understood, so we can define a "scenario" aka audio stack for cmt that is _not_ using AEP
<jonwil>
the policy stuff (aka policy-application-detector, policy-settings-rx51, alsa-policy-enforcement) has nothing to do with this
<jonwil>
Its all configured by a set of .parameters files in /var/lib/pulse-nokia
<DocScrutinizer05>
well, something in all that stuff is configuring the audio stack for a certain usecase
<jonwil>
The decision on which .parameters file to read comes from module-nokia-voice. Let me check some more
<DocScrutinizer05>
and no matter if policy-foo tells PA "please load nokia-voice" and then PA reads in .parameters files, we need to make sure there's a difference in which .parameters are read for cmt and for SIP
<DocScrutinizer05>
so we need to understand the whole hairball anyway
<jonwil>
following back how it sets the "mode"
<jonwil>
it somehow passes x-maemo.mode and x-maemo.accessory_hwid to module-nokia-voice
<jonwil>
those are how it determines the parameter set to use
<jonwil>
Lets see where they come from as that will be the interesting part
<DocScrutinizer05>
yeah, /var/lib/pulse-nokia/* is a great finding
NIN101 has joined #neo900
<jonwil>
those files make interesting reading :)
<jonwil>
at least in the sense of explaining the different modes and what they turn on and off
<DocScrutinizer05>
indeed, when we find where those x-maemo.mode and x-maemo.accessory_hwid come from, we won that battle
<jonwil>
yeah I nearly found those
<jonwil>
module-alsa-sink-volume (
<jonwil>
which is FOSS
<jonwil>
module-policy-enforcement also FOSS
<jonwil>
module-stream-restore, I think thats foss
<DocScrutinizer05>
we need to document the whole stuff in /var/lib/pulse-nokia/* files, so we at least have a faint clue what to tweak in which way to adjust it to our new hw
<jonwil>
we will be able to document what its doing once we have cloned the code that uses it
<DocScrutinizer05>
yep
<DocScrutinizer05>
at least psrts of it ;-)
<jonwil>
its possible the info we get from jusa_ (whatever that might be) will help us with this area too
<DocScrutinizer05>
parts. Those we really understand how they work
<DocScrutinizer05>
yes, I'm hoping a lot for jusa_with this
<jonwil>
so yeah the bits that touch x-maemo.mode are FOSS
<jonwil>
I dont know about aep.parameters but for example x-maemo.limiter.dl.parameters and x-maemo.limiter.ul.parameters are understood simply by studying the code that grabs that info and feeds it to the drc code
<jonwil>
i.e. if we have the code, we will know what the parameters are
<jonwil>
and how the code uses them
<DocScrutinizer05>
yup
<DocScrutinizer05>
<DocScrutinizer05> parts. Those we really understand how they work
<DocScrutinizer05>
stuff like "x-maemo.wb_eeq = "false"" is pretty obvious and prolly convenient to use
<jonwil>
A lot of the parameters are going to be inputs into mathematical algorithms we dont necessarily understand
<jonwil>
even with code for said algos
<DocScrutinizer05>
other stuff might become a headache: x-maemo.aep.parameters = x-maemo.cmt.ul_timing_advance = x-maemo.aep.switches = x-maemo.ear_ref_padding = ...
<DocScrutinizer05>
jonwil: ((mathematical algorithms we dont necessarily understand)) that's my point
<DocScrutinizer05>
and I hope for jusa_ to help out when we get stuck there
<jonwil>
anthow, looking at -voice, I see (among other things) 3 instances of iir eq being created and one instance of fir eq
<jusa_>
I'm still quite sick, and I have lousy memory, so please ask more where I have not written much..
<jonwil>
thats great info, it helps
<jonwil>
function init_main looks like very very very very useful piece of info for the aep bits, its the function that takes the aep parameter stuff and does stuff with it
<DocScrutinizer05>
jusa_: many thanks! and get well soon, friend!
<jonwil>
Whats useful about it is that it looks like it was at one point a main() function for an exe of some sort
<jonwil>
and has a "usage" printout inside
<DocScrutinizer05>
jusa_: please clarify what exactly you refer to when you say "meego"
<jonwil>
I am guessing "meego" means the meego blobs
<DocScrutinizer05>
there been at least genuine meego (driven with intel on board), and the meego moniker "maemo" harmattan which shipped with N9
<DocScrutinizer05>
aiui the genuine meego eventually turned into mer
<jusa_>
yeah.. that's actually really difficult..
<jusa_>
meego != harmattan
<jusa_>
meego is really fork of harmattan maybe a year prior n9 launch, meego was then the intel project.. in the end some of the harmattan stuff was merged to meego and vice-versa, but it was a mess
<jonwil>
aha, now I see, mudrc stands for "multiband udrc"
<jonwil>
Not sure what the u in udrc is for though
<jusa_>
MUltiband DRC
<jonwil>
what is ALWE?
freemangordon1 has joined #neo900
freemangordon has quit [Read error: No route to host]
<jusa_>
dunno
<DocScrutinizer05>
>>XProt displacement - don't remember. Something about the speaker coil safe traversal probably.<< wow, pretty bizarre :-.)
<DocScrutinizer05>
jusa_: do you know what exactly killed the speakers in N900?
<DocScrutinizer05>
heat? mechanical damage?
<DocScrutinizer05>
I guess must be heat, since otherwise why would XPROT ask for temperature sensor readings
<jonwil>
Once we get a good look at the math inside a_xprot_func and a_xprot_func_s we should know what xprot displacement is
<jonwil>
Anyone know what iAVC or VAD are?
<jusa_>
DocScrutinizer05: not really
<jonwil>
fft is fast fourier transform, that much I know
<jonwil>
agc is automatic gain control
<jonwil>
aec is acoustic echo cancellation
<jonwil>
no clue what shc is
<jonwil>
or wnr
<jonwil>
oh wait, shc must be "sidetone howling control"
<DocScrutinizer05>
audio TLA Bs bingo ;-)
<DocScrutinizer05>
BS*
<jonwil>
and wnr must be "windnoise reduction"
<DocScrutinizer05>
wut?
<DocScrutinizer05>
lol
<DocScrutinizer05>
funny
<DocScrutinizer05>
makes sense though
<jusa_>
afaik the AEP is really good algorithm package
<jonwil>
abe is "artificial bandwidth expansion"
<jonwil>
Just from looking at the code I can see that its doing a LOT of math
<jusa_>
or was..
<DocScrutinizer05>
jusa_: I bet on that, it's one of nokia's most valuable assets
<jusa_>
DocScrutinizer05: yep
<jonwil>
yeah I saw a pile of the patents for it the other day :)
<jonwil>
or what appear to be patents related to aep
<jonwil>
not that I can read patenteze...
<DocScrutinizer05>
wow, abe. That means the stuff is calculating which harmonics are supposed to be there - given the sound source (human voice) - but are not due to bandwidth limitations, and then tries to synthesize and add those missing harmonics (and possibly sub-harmonics too)
<DocScrutinizer05>
DBX BOOMBOX did similar stuff for sub-bass in the 1970s
<jonwil>
I used to think the most complex piece of software on the N900 was the GPU driver with the pulseaudio blobs comming a close second. I was wrong, the pulseaudio blobs ARE the most complex piece of software on the either N900
<jusa_>
yeah.. it was fun when other developers were complaining "you are consuming 20% of cpu during voice call".. and we were like "wtf don't you know what we run with 5ms buffers, in ONLY 20% cpu"
<jusa_>
and that with ARM, not audio DSP
<DocScrutinizer05>
:-D
<DocScrutinizer05>
usual devels have no idea what real heavy signal processing in relatime means
<jonwil>
I dont know how pulseaudio-module-nokia-*-dbg packages ended up in the Harmattan SDK repository and I dont wanna know but boy am I glad they did, they are so useful :)
<DocScrutinizer05>
hehe
<jusa_>
:)
<DocScrutinizer05>
courtesy Nokia engineers who felt unhappy about closed
<DocScrutinizer05>
we seen that several times
<freemangordon1>
yeah, without those it would have been impossible to do what we already did and plan to
<freemangordon1>
why am I fmg1?
<jonwil>
anyhow it definatly looks from what we have that we dont need to bother cloning the stereo widening code
<DocScrutinizer05>
[2014-10-26 Sun 11:01:40] <-- freemangordon (~ivo@46.249.74.23) has left this server (Read error: No route to host).
<freemangordon1>
yep, I restarted my router
<freemangordon1>
so what?
freemangordon1 has quit [Quit: Leaving.]
freemangordon has joined #neo900
<jonwil>
it also looks (from what I am seeing in pulseaudio-nokia-voice) that the idea of "forget what the Nokia code is doing and find FOSS algorithms we can plug into the gaps on that diagram" is not going to fly
<freemangordon>
:nod:
<DocScrutinizer05>
jonwil: definitely we don't need nor want stw
<DocScrutinizer05>
jonwil: yeah, assuming we want to re-use the .parameter files it won't fly
<freemangordon>
as I already said, I'll RE that when we have all the other stuff already in place
<DocScrutinizer05>
but as jusa_ and I explained, _none_ of all that is really essential for a working modem voice call
<freemangordon>
sure
<freemangordon>
but I'd rather try to have the maximum
<DocScrutinizer05>
you can (and prolly should) drop the complete AEP for voicecalls via Cinterion modem
<DocScrutinizer05>
ack
<DocScrutinizer05>
nice to have (or even more than just nice) for VoIP anyway
<freemangordon>
jusa_: BTW, all that NEON stuff - is it hand-crafted or that's what armcc did?
<DocScrutinizer05>
but I think we could safely drop/ignore/replace-by-dummy stuff like stw and abe
* jonwil
is glad he wont be the one tackling the MASSIVE pile of FPU/NEON at the heart of EAP
<jonwil>
I mean AEP
<DocScrutinizer05>
it's very Nokia proprietary and complex stuff, that just implements the last icing on top regarding audio quality
<freemangordon>
hehe :)
<jusa_>
freemangordon: NEON stuff is hand optimized for the n900 cpu
<DocScrutinizer05>
WOW!
<freemangordon>
hmm...
<freemangordon>
weird
<DocScrutinizer05>
jusa_: you guys did a hell of a job, eh? kudos!
<jusa_>
not that complicated stuff in the end, just copying stuff, doing interleaving/de-interleaving
<jusa_>
iirc
<DocScrutinizer05>
all the more annoying to hear "wtf you're using 20% CPU..."
<DocScrutinizer05>
I'd answer "don't you think the remaining 80% are sufficent for your... err what was it you intended to do during a voice call?"
<Wizzup>
DocScrutinizer05: compiling gentoo of course!
<jusa_>
that 20% wasn't even with max frequency
<freemangordon>
jusa_: I asked because I was wondering if gcc4.2.1 is better than armcc, as for the most stuff I REed so far containing NEON code, gcc intrinsics produce faster code than what's already in place
<DocScrutinizer05>
Wizzup: :-P
<freemangordon>
but being hand-crafted it makes sense to be slower
<freemangordon>
anyway, /me is going afk, see you later guys
<DocScrutinizer05>
cya freemangordon
* DocScrutinizer05
is heading out too, to have a sunday with decent breakfast
<DocScrutinizer05>
jusa_: would you mind me copying your user:talk to the "main" wiki page?
<jusa_>
DocScrutinizer05: sure, I just wasn't sure what the "main" wiki page was, and wanted to have something written down..
<DocScrutinizer05>
np, I will take care
<DocScrutinizer05>
and probbaly eventually chainsawbike
<DocScrutinizer05>
chainsawbike: ^^^ could you help with a bit of wikifying stuff?
<DocScrutinizer05>
I created the latter, but failed to properly categorize it and link it into directory
<jonwil>
It sounds like from a pure algorithm perspective we COULD take pulseaudio-modules-meego and pulseaudio-nokia from the Meego-on-N900 work along with pulseaudio-settings-N900 and use it on Fremantle without any loss of functionality. That doesn't account for legal issues with redistributing the pulseaudio-nokia blobs OR the differences in pulseaudio version, libc version or abi though.
<jonwil>
Neo900 group shouldn't be distributing any audio stuff at all
<jusa_>
now I think I'll take a nap.. :) cu ->
<jonwil>
Just a phone with a bootloader and flashing setup so the user can flash the OS of their choice
<DocScrutinizer05>
cya jusa_
<jonwil>
whether it be Replicant
<DocScrutinizer05>
get well soon!
<jonwil>
or Fremantle-on-Neo900
<jonwil>
or whatever else
<DocScrutinizer05>
yep, that's what Neo900 group will do
<DocScrutinizer05>
ship a combined "image" consisting of said flash-your-own "wizard" plus a BSP&factory-test hybrid
<DocScrutinizer05>
the BSP&factory-test will have some charming but basically pretty limited GUI so users don't suffer a "meh, how useless" shock on first boot
<DocScrutinizer05>
maybe some video clip welcome, explaining what's that device you're just watching, plus doing some tricks like initiating a phonecall and blinking all the bazillion of shiny LEDs we have
<DocScrutinizer05>
basically nonsense but some eye candy
<jonwil>
Will the host-side flashing program and drivers for the Neo900 be FOSS or not?
<DocScrutinizer05>
sure
<DocScrutinizer05>
uBoot may support DFU
<DocScrutinizer05>
drivers are all FOSS of course
<DocScrutinizer05>
we cannot provide any non-FOSS drivers, where from we could get those anyway?
<jonwil>
good point
<DocScrutinizer05>
Neo900 UG has basically no access to sources that were not available to any of you as well
<jonwil>
yep :)
<DocScrutinizer05>
that's the foundation paradigm of us calling the device "open"
<DocScrutinizer05>
we won't keep anything closed. We don't even have anything we could keep closed
<DocScrutinizer05>
(except of hw design, which we will disclose as well)
<DocScrutinizer05>
(at least 90% of it)
<DocScrutinizer05>
what we might not disclose is data about how to produce the device, like reflow profiles, exact footprint data, component sources, aso
<DocScrutinizer05>
stencil
<DocScrutinizer05>
exact type of solder paste
<DocScrutinizer05>
stuff like that
<jonwil>
The Neo900 will be the most open cellphone ever made
<jonwil>
and certainly the only open cellphone to support modern data standards
<DocScrutinizer05>
you only would need that stuff to start your own production, and we don't want our customers to pay more just to facilitate somebody else starting a competing project cloning the whole device incl production process
<DocScrutinizer05>
so e.g. the PCB might get documented in a way that's precise enough so you can evaluate it (and do whatever tweaks you like, even up to stuff like drilling holes into PCB) but the data might not be suited to send it to a PCB house and produce a working PCB from it
<jonwil>
Will Neo900 have any new plastic bits or case components or etc?
<jonwil>
IIRC it needs a spacer somewhere for some reason
<DocScrutinizer05>
yes
kolp has joined #neo900
<jonwil>
ok, enough PulseAudio fiddling for now, I have to write some code for an unrelated project :)
<DocScrutinizer05>
for spacer I hope for a few guys in community who offered to eventually provide a 3D CAD design for a first 3D prototype printout. Neo900 UG even offers to subcontract professional work for that
<DocScrutinizer05>
Sorry I can't take leadership in that sub-project right now
* DocScrutinizer05
frowns a little at WG7351 leakage current in off mode of up to 26µA
<kolp>
would be nicer in hardware :)
<kolp>
but software is fine, too
<DocScrutinizer05>
prolly we should consider the power switch for modem rather a RF-killswitch for WLAN as well
<kolp>
what exactly is hackerbus?
jonwil has joined #neo900
b1101 has quit [Quit: b1101]
Wizzup has quit [Quit: leaving]
trench has quit [Ping timeout: 245 seconds]
b1101 has joined #neo900
trench has joined #neo900
<Oksana>
different audio profiles... adjustable by user ... by request to Cinterion ... Great.
<Oksana>
Maemo 5 can be run on N9?
Wizzup has joined #neo900
<Oksana>
"windnoise reduction"? I do not remember it working well. Though, to be fair, it was windy-sandy day, long ago. And, having two microphones will help with it, I hope.
<Oksana>
:) jusa_yeah.. it was fun when other developers were complaining "you are consuming 20% of cpu during voice call".. and we were like "wtf don't you know what we run with 5ms buffers, in ONLY 20% cpu"
<Oksana>
About southern hemisphere: there are heat waves, with blue sky, and no clouds. The fires have not started yet, but the grass is yellow, and water is lacking - for earth worms and other 'wildlife', at least (humans have access to tap-water and bottle-water, as usual). Spend eight hours outdoors, and you will get a headache from too-much-sun, too-hot-weather. The day is lucky if there is a...
<Oksana>
...rain at night. And a flu is travelling in the cities - because it's spring?
<Oksana>
zilch from Gerry - maybe, you should send a letter to him? Or would he read English if I sent him a letter? And yes, I have not received the Nokia's battery charger, yet - a week late, already.
<Oksana>
Heh, these Italians are already asking me to make an assessment of the product ordered. When it was not delivered yet :)
<Oksana>
Oh, and about southern hemisphere: blue-bottles (aka Portuguese man-of-war) are common here (at least, on the sand of the beach), remnants of sea urchins by sea gulls can be easily found on the stones, and sting ray, buries under sand, may await careless sea-walker.
<Oksana>
Good morning! Is anybody here?
<MonkeyofDoom>
morning
<Oksana>
Morning :)
<Oksana>
Well, public implementation of modem firmware is unlikely, but maybe, they could provide "open" source-code of the modem firmware to those device manufacturers who both buy the modem-chip and request the code; with some EULA or something that they cannot share it outside the company; and then, the device manufacturer could audit the firmware, fix any bugs it finds, tells users about any bugs...
<Oksana>
...it finds, and so on.
<Oksana>
With contractual employment of interested members of the community so that they would be able to see the code, and take part in its development, too. Even if the code itself cannot be made public... For what reasons cannot modem's firmware's code be made public, again?
nox- has joined #neo900
<Oksana>
Good morning!
<enyc>
Oksana: though, in neo900, by 'isolating' the modem it is not considered a risk... data send over the network is available to the network anyway, etc.
obsed has joined #neo900
<enyc>
Oksana: at least, it shouldn't be able to ... read all the host memory via some backdoor etc
<Oksana>
Yes, I know. But having access to firmware code would be nice. Imagine: peer-to-peer network of mobile phones, without cellular towers?
paulk-aldrin has quit [Quit: Ex-Chat]
<DocScrutinizer05>
BWAHAHAHA
<DocScrutinizer05>
sorry
<Oksana>
Yes, I know that it's not that easy. Cellular towers are made for a reason, aka : obstacles, line-of-sight, et cetera. And peer-to-peer network requires dedication from users to allow their phones to be used as middle-stations.
<Oksana>
No problem :)
<Oksana>
I sent a wall of text earlier?
<DocScrutinizer05>
but that's *exactly* why no modem manuf will allow "community2 to flash firmaware to their chip
<DocScrutinizer05>
the band is *owned* by carrier, and carriers have no interest in allowing some peer 2 peer citizenband-type smalltalk chat on their frequencies, ruining the normal GSM/UMTS traffic
<DocScrutinizer05>
and nobody will give you FCC approval for any such funny idea of cellphone abused as walkietalkie
<Oksana>
Well, people can FM-transmit music-or-whatever from phone to car-FM-receiver, and major FM-transmitters do not ban this :)
<DocScrutinizer05>
so even when you could get the firmware into doing such stuff, you'd operate a *highly* illegal transmitter. Fines vary between 50000 bucks and 20 years in jail for that
<Oksana>
Well, I am trying to find FCC-like agency in my country and figure out its requirements.
<Oksana>
A mobile phone would simply not have enough power to significantly disrupt the nearby 'normal' GSM/UMTS traffic :)
<Oksana>
Right?
<DocScrutinizer05>
haha
<DocScrutinizer05>
a single cellphome can take dowen a whole BTS with 30km radius
<Oksana>
Hn... You are giving ideas. Can it take down an aircraft, when the cellphone is inside the aircraft, too?
<DocScrutinizer05>
GSM/UMTS is not "nearby", you are abusing the exact freuqnecies
<DocScrutinizer05>
frequencies*
<DocScrutinizer05>
allegedly yes, but actually no
<Oksana>
They have multiple bands within a band, to speak with many phones at the same time?
JoHnY_ is now known as JoHnY
<DocScrutinizer05>
unless you use BT or WLAN to hack the fly-by-wire computers
<Oksana>
What frequencies do aircraft devices use? For speaking with the ground, and else?
<DocScrutinizer05>
and for "GSM 101" please use google, I am too tired right now
<DocScrutinizer05>
every BTS has a CBC
<DocScrutinizer05>
a sincle channel for controlling the whole zoo of cellphones serviced by the BTS
<Oksana>
:) Have you read the wall of text? About southern hemisphere? :) zoo?
<MonkeyofDoom>
when trying to donate, I get "The card you entered cannot be used for this payment. Please enter a different credit or debit card number." no matter which card I use
<MonkeyofDoom>
any clues why that might be?
<MonkeyofDoom>
(using a debit card)
<DocScrutinizer05>
sorry, no idea. Neo900 UG offers money transfer per SEPA/SWIFT, and paypal
<MonkeyofDoom>
yeah, I'm using the paypal one
<DocScrutinizer05>
no idea what paypal does
<MonkeyofDoom>
I would have expected it to be pretty straightforward since I'm in the US but idk
<MonkeyofDoom>
:/
<Oksana>
Heh... I have a debit card, too? I used an IBAN bank transfer?
<DocScrutinizer05>
I'd be surprised if paypal card handling would depend on destination of your payment
<DocScrutinizer05>
yes, for donations nothing but subject with your real email address and country of usage for device matters
<DocScrutinizer05>
for *us*
<Oksana>
Try changing e-mail address when attempting to pay again? Different browser (so that cookies would not be remembered) ?
<DocScrutinizer05>
no idea about PP
<Oksana>
Yes, because Neo900 is not shipping anything, yet :)
<MonkeyofDoom>
mmk
<kolp>
Oksana: local/personal FM transmitting is highly limited (as in 'output power') by frequency regulators :)
<kolp>
can't be compared to peer-2-peer chat stuff :)
<MonkeyofDoom>
it worked now :)
<MonkeyofDoom>
(didn't touch shipping address)
<DocScrutinizer05>
kolp: hackerbus is a number of interfaces in battery compartment where you can attach your own hw extensions. Tentative interfaces: I2C, USB, wake IRC, VBUS5Volt, Vbatt, Audio in
<Oksana>
Hn, so local-personal cellular transmitting could also be limited. Though, I admit, figuring out the local walkie-talkies is easier than trying to use the cellular frequencies for P2P purpose. 1. Legality. 2. closed firmware. 3. infrastructure/usability.
<kolp>
DocScrutinizer05: ah, that sounds cool. When you said 'inclusion not considered', does that mean 'will definitely not be in neo900'?
<DocScrutinizer05>
yes
<DocScrutinizer05>
it's too special
<Oksana>
Only as third-party accessory :)
<kolp>
ok
<DocScrutinizer05>
anyway you can plug in a whatever-DIY-or-by-3rd-source such receiver to hackerbus, and maybe you even can fit it under the standard battery lid
<DocScrutinizer05>
I might add it to my tricorder "TOH" ;-)
<DocScrutinizer05>
my pet project for after Neo900 succeeded
che1 has quit [Ping timeout: 265 seconds]
kolp has quit [Remote host closed the connection]
DocScrutinizer51 has quit [Read error: Connection reset by peer]