Just a quick bug fix to gsm322.c. Basically, there were two commands in an "else" block without brackets, causing the
"end = 1023+299"
command to execute regardless of the state of index.
Kurtis Heimerl wrote:
Just a quick bug fix to gsm322.c. Basically, there were two commands in an "else" block without brackets, causing the
"end = 1023+299"
command to execute regardless of the state of index.
hi kurtis,
thanx for this fix. applied it.
can you tell how you found it? what behavior did you experience?
best regards,
andreas
I'm currently trying to figure out how to (out of GSM spec) get osmocom to camp to a specific ARFCN. I tried using this function and noticed it wasn't limiting the scan as it was supposed to.
On Wed, Feb 1, 2012 at 11:34 PM, Andreas Eversberg andreas@eversberg.eu wrote:
Kurtis Heimerl wrote:
Just a quick bug fix to gsm322.c. Basically, there were two commands in an "else" block without brackets, causing the
"end = 1023+299"
command to execute regardless of the state of index.
hi kurtis,
thanx for this fix. applied it.
can you tell how you found it? what behavior did you experience?
best regards,
andreas
I think I looked at that... I'll give you some context.
We've modified osmocom to "wakeup" a specific tower at a specific ARFCN. We then want to scan and camp on that arfcn as soon as it wakes up (without scanning the rest of the ARFCNs available). If I remember correctly, stick still scans the whole band... but discards them and only attaches to the "stuck" ARFCN, though I could be mistaken. If it works, it will save us a bunch of time. I'll definitely look at it in more depth tomorrow.
Thanks for the direction!
On Thu, Feb 2, 2012 at 12:04 AM, jolly andreas@eversberg.eu wrote:
Kurtis Heimerl wrote:
I'm currently trying to figure out how to (out of GSM spec) get osmocom to camp to a specific ARFCN. I tried using this function and noticed it wasn't limiting the scan as it was supposed to.
try that at the vty:
enable conf t ms 1 stick <arfcn> [pcs] write
On Thu, Feb 2, 2012 at 12:08, Kurtis Heimerl kheimerl@cs.berkeley.edu wrote:
I think I looked at that... I'll give you some context.
We've modified osmocom to "wakeup" a specific tower at a specific ARFCN.
Interesting. Do you mean you send some packet to a "sleeping" BTS to wake it up?
Yeah, and we have that working.
On Thu, Feb 2, 2012 at 12:56 AM, Alexander Chemeris alexander.chemeris@gmail.com wrote:
On Thu, Feb 2, 2012 at 12:08, Kurtis Heimerl kheimerl@cs.berkeley.edu wrote:
I think I looked at that... I'll give you some context.
We've modified osmocom to "wakeup" a specific tower at a specific ARFCN.
Interesting. Do you mean you send some packet to a "sleeping" BTS to wake it up?
-- Regards, Alexander Chemeris.
Is it a part of your TIER university work? I wonder about use cases for this.
One use case I see is when you have a BTS which is rarely used, like in a desert and you don't want it to work all the time. What use cases do you plan to use it for?
On Thu, Feb 2, 2012 at 22:03, Kurtis Heimerl kheimerl@cs.berkeley.edu wrote:
Yeah, and we have that working.
On Thu, Feb 2, 2012 at 12:56 AM, Alexander Chemeris alexander.chemeris@gmail.com wrote:
On Thu, Feb 2, 2012 at 12:08, Kurtis Heimerl kheimerl@cs.berkeley.edu wrote:
I think I looked at that... I'll give you some context.
We've modified osmocom to "wakeup" a specific tower at a specific ARFCN.
Interesting. Do you mean you send some packet to a "sleeping" BTS to wake it up?
-- Regards, Alexander Chemeris.
-- Regards, Alexander Chemeris.
This is part of my thesis work at Cal, yes. Range is not in any way involved.
That's roughly the use case, areas where there are too few users to keep a BTS in constant use. Our designs allow the power usage to scale with the number of users, rather than sit at a fixed output, as they do now. The BTS side is simple; the osmocom side is complicated. We have a handset that can wakeup a sleeping tower, or a "wakeup button" device which only transmits when a button is pressed. That thing is ~5 bucks and can probably be attached to the back of a legacy phone in case we can't convince a large manufacturer to incorporate our changes into the baseband.
Anyhow, the code is online if you're interested in looking at our progress (https://github.com/kheimerl). It's nowhere near ready, but you're a very knowledgeable guy, and I'd be happy to hear your opinions on any of our designs.
On Thu, Feb 2, 2012 at 10:37 AM, Alexander Chemeris alexander.chemeris@gmail.com wrote:
Is it a part of your TIER university work? I wonder about use cases for this.
One use case I see is when you have a BTS which is rarely used, like in a desert and you don't want it to work all the time. What use cases do you plan to use it for?
On Thu, Feb 2, 2012 at 22:03, Kurtis Heimerl kheimerl@cs.berkeley.edu wrote:
Yeah, and we have that working.
On Thu, Feb 2, 2012 at 12:56 AM, Alexander Chemeris alexander.chemeris@gmail.com wrote:
On Thu, Feb 2, 2012 at 12:08, Kurtis Heimerl kheimerl@cs.berkeley.edu wrote:
I think I looked at that... I'll give you some context.
We've modified osmocom to "wakeup" a specific tower at a specific ARFCN.
Interesting. Do you mean you send some packet to a "sleeping" BTS to wake it up?
-- Regards, Alexander Chemeris.
-- Regards, Alexander Chemeris.
baseband-devel@lists.osmocom.org
-
Alexander Chemeris -
Andreas Eversberg -
jolly
-
Kurtis Heimerl