I’ve been looking into building a timer and selling it (I do embedded development, bluetooth, microcontrollers, etc., for a living and understand the complexities of this).
Is there an ICD for the Bluetooth Low Energy connection to the PS apps? If so where is it?
If not, do timer manufacturers really have to wait for PS to modify the software to support the timer? If this is the case, that puts a lot of risk on the timer manufacturer for something that may never talk to PS apps. Again, if this is the case, could/would PS develop a generic protocol that can be used going forward?
@Brad_Millard usually, the timer manufacturers are not building timers just for having them to connect to PractiScore apps and making their business depending on that…
From the past experience. Each device we integrated with has its own unique features and those not necessary all fold into some common protocol. Besides, not being in the hardware manufacturing business it puts a extra load on the PractiScore team to support unverified hardware integrations, which we currently can’t afford.
You could define a minimum protocol since you have certain functionality. Unless your adding different functionality to PS for each timer (which I doubt). A virtual serial port with a serial protocol would work well and be more easily expandable.
Creating BLE hardware to test with is easy. You can do it with off the shelf BLE development boards for a couple days work.
The issue I have is that molds and product development can cost 10s of thousands of dollars with no guarantee we would be able to use it with PS. That’s not going to happen, so the project is dead before it starts.
That’s unfortunate… But you also can’t expect PractiScore to invest 10s of thousands of dollars of developer’s and support time to hook up with a flaky hardware someone tossed in a dev board and chatgpt’ed in an evening.
In reality it is much much more involved than using virtual serial port. Ask me how I know…
The AMG Lab and other timer manufacturers did their home work, developed their hardware, made sure that hardware works with pretty much arbitrary tablets, developed software protocols and worked out all kinks in it. Also wen through multiple iterations of their hardware and software with us.
Now I’m curious. Are you asking PractiScore to do most of that homework, so you can get it for free and just start selling your devices?
Not necessarily. I would like to see an ICD (you already support multiple timers) for a generic interface. I have developed a number of different devices and done interfaces to tablets and phones (I did both ends). I can do all the home work in the world, get the device built and still not get it connected to PS because you’re (understandably) busy. In fact, I can’t even test the interface without getting you involved. Frankly, I’m very surprised you work this way at all.
You keep talking about PS doing all the homework, but then in the same post, you talk about multiple iterations of their hardware and software. That can’t be efficient. I have to believe it would be easier to support a generic interface and not have to deal with the hardware manufacturers through multiple iterations.
In my experience, just about everyone uses PS for their matches. That makes connectivity for a timer very important.
What you have now is “create your timer and maybe we’ll support it”. As I said before, that puts a lot of risk on the hardware developer - to the point that it won’t get developed.
That is not accurate. We are open to support products that are available on the market (though there are some basic administrative conditions). But it is a whole different story to support something that has been put together on a dev board and be a frontline support for that.
If your business plan has PractiScore apps connectivity as the only thing for your product to success. It pretty much positions PractiScore as your free service supplier. That hasn’t been the case with device manufacturers we’ve been working with.
Bottom line. Not being a hardware manufacturer, we don’t have bandwidth to develop and maintain hardware communication spec and to make sure devices that use that spec are 100% compliant and reliable (in multiple aspects).
This is going nowhere. I don’t know why you keep talking about supporting something on a dev board. When did I ask you do do that? I said I could do something on a dev board in a few hours to test a known interface.
Is PS willing to sign a contract saying they’ll support something? I bet not, which means you don’t have to. That’s the bottom line. All your talk about committment doesn’t really mean anything.
You don’t have the time to maintain a hardware communication spec, but you maintain many different communication protocols for different timers. Again, doesn’t make sense. I can understand that when you started, you wanted to support existing timers. But I can’t see this model scaling well. It’s going to be a support nightmare.
You basically asking PractiScore to develop, publish and then maintain connectivity specification. Then anyone can grab a dev board, a serial to BLE dongle, etc and toss together a device based on that.
The next thing that is going to happen when that device is used in the field and it does not work or cause any issues. The PractiScore support channel is going to be called and it takes time to figure out what the issue is.
And now we would have to do that without having that hardware at hand to test with.
A contract is something for two parties to commit to.
If you want PractiScore to work with you through your R&D and development phases, and/or develop a hardware communication protocol for you, send an offer to support@practiscore.com and we can talk.
We don’t maintain many different communication protocols. Those protocols are owned and maintained by hardware manufacturers. We only consuming these protocols.
On a contrary. Once hardware development is done and PractiScore completed integration with it, that pretty much seals the deal and certifies that device can be connected to and can talk to PractiScore.