Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 06 2016 21:30
    afelicioni starred friends-of-pebble/bam
  • Oct 08 2015 21:00
    matthewtole closed #3
  • Oct 08 2015 21:00
    matthewtole closed #1
  • Oct 08 2015 21:00
    matthewtole closed #2
  • Apr 20 2015 16:45
    matthewtole commented #3
  • Apr 20 2015 16:38
    cynorg commented #3
  • Apr 20 2015 12:17

    matthewtole on protocol

    Reduce number of bytes used for… (compare)

  • Apr 20 2015 12:17
    matthewtole synchronize #3
  • Apr 20 2015 12:12
    matthewtole opened #3
  • Apr 20 2015 12:12

    matthewtole on protocol

    Create message-header.md (compare)

  • Apr 20 2015 12:08

    matthewtole on protocol

    (compare)

  • Apr 19 2015 21:35
    Travis friends-of-pebble/bam-c (feature/unit-test-framework) passed (13)
  • Apr 19 2015 21:35
    Travis friends-of-pebble/bam-c#1 passed (14)
  • Apr 19 2015 21:34
    matthewtole synchronize #1
  • Apr 19 2015 21:34

    matthewtole on unit-test-framework

    Fix the Travis installation scr… (compare)

  • Apr 19 2015 21:20
    Travis friends-of-pebble/bam-c#1 errored (12)
  • Apr 19 2015 21:19
    Travis friends-of-pebble/bam-c (develop) passed (11)
  • Apr 19 2015 21:19
    matthewtole opened #1
  • Apr 19 2015 21:19

    matthewtole on develop

    (compare)

  • Apr 19 2015 21:18
    Travis friends-of-pebble/bam-c@7954ef9 (feature/unit-test-framework) errored (10)
Martin Norland
@cynorg
forehead
cynorg @cynorg slaps his forehead
Martin Norland
@cynorg
I'm a little PKJS spoiled with my 2KB
Matthew Tole
@matthewtole
I was thinking that we’d need a few bytes at the beginning of each message:
BAM_VERSION
MESSAGE_ID
SEGMENT_ID
RETRY_COUNT?
Obviously need to keep it as small as possible.
Like a byte for each?
Also need something for the type of data we’re sending
Martin Norland
@cynorg
does the retry need to be inside the message itself? That seems, like priority, to be a local implementation detail
layering this on top of a 126 byte appmessage sure makes things thin
Matthew Tole
@matthewtole
True
Martin Norland
@cynorg
I guess if we only end up with 8 bytes or less, it's still a sizable win (hell, even if we used ~30 of the bytes, it's likely still very much worth it)
but yeah, minimizing the header/encapsulation is important, definitely minimize what goes into it where possible
Martin Norland
@cynorg
should we worry about AppSync at all, or do we think it's safe to assume that anyone using AppSync isn't ... really programming ;)
similarly (though more seriously) should C side have something for wrapping BAM messages inside datalogging
Matthew Tole
@matthewtole
Ooh that could be interesting
The second one I mean
Not MVP though
Martin Norland
@cynorg
no indeed not
I suppose, conceptually, that doesn't affect the protocol - it'd just be C function(s)
I've gotta get back to doing some actual work-related work - but I'd meant to ask, how did you seamlessly migrate your bam-* repositories to the new organization?
Matthew Tole
@matthewtole
I just changed the organisation
After renaming the organisation to hopefully not violate the Pebble trademark.
I’m hoping that “of Pebble” is as acceptable as “for Pebble” :/
I might rename it again before we launch.
Martin Norland
@cynorg
oh, I thought it was part of smallstoneapps
Matthew Tole
@matthewtole
It was
You can move repos between orgs
Martin Norland
@cynorg
yeah, Timely's github repo is still PebbleTimely - I may submit a request to github support to rename that
I don't think, ultimately, they really care
Matthew Tole
@matthewtole
You can rename repos yourself
In settings
Martin Norland
@cynorg
<--gitnoob
is there any way to ensure a redirect remains in place
Matthew Tole
@matthewtole
It’s not called PebbleTimely on the store is it?
Martin Norland
@cynorg
lord no
Matthew Tole
@matthewtole
We don’t care about repo names
I don’t think
So don’t bother.
But yeah, GItHub auto redirects
Martin Norland
@cynorg
good to know
finebyte
@finebyte
re MVP, I think simple queue system may really mean reliable messaging?
also just thinking about implementation is messaging to the pebble more important than messaging from the pebble?
I know I mostly ignore message drops from the pebble and I personally don't send much data from pebble to phone
just button clicks in fact
Matthew Tole
@matthewtole
Definitely agree on the second point. Also the buffers are so much smaller going to the Pebble (along with that being the bigger data direction) that that’s where the best gains are to be had. I still think that we should implement both sides simulteanously.
Martin Norland
@cynorg
the only real way to create any volume of data on the pebble is by having received it from the phone (at which point, probably best to cache it there tied to the watch identifier) or by using the accelerometer - but the buffers on the watch side also affect how many bytes our segments identifiers need to be
and phone -> watch is definitely the vast majority of use cases, anyone doing accelerometer will either want to hyper-optimize whatever is doing their AM, or use datalogging
finebyte
@finebyte
At the moment I use a queue on the android side which sends next message on receipt of the ACK or resends on NACK. It has a number of situations where it just resets the queue and starts initialising the pebble app from scratch. It is not 100% reliable and it would be nice to work out why. I sue a header which is a little redundant - it tells me the message id, length of the complete message, the start position of this block and the length of this block. I then simply memcpy the bytes into an array at the right point and stop when I think I have the total number of bytes in the message.
I used to have a "flood and resend" mechanism that just sent everything as fast as possible then resent the NACKs. This works for fairly small messages