Updating sensors and going forwards

So, today I’ve been looking at alternate chips for the sensors, as to add the extra medical and reporting systems to the current sensors based on the Picaxe 08M2 is really pushing the envelope of what it can do.

August Arcturus update

Well, it has been a little while since last update, but then, there hasn’t been a huge amount to update yet as real-life & health reared it’s head for a little while over the summer.

That hasn't stopped planning and work on Arcturus overall though.

I did tinker with LCD/Oled displays for Arcturus to add info , but I’m not happy with how they are handled via picaxe basic so they will need to be something I work on in C, which I’m partway through getting up to speed with.

However, that hasn’t stopped work on the existing Arcturus system sensor and emitter prototypes.

The sensors have had a quite extensive upgrade following the feedback at Babylon 5, along with implementation of the various effects – The problem now is the chip being used in the sensor (Picaxe 08M2/PIC 12F1840) is running critically low on code space. So to include a medical system/medic box could possibly need switching to C, which I think would give some efficiencies over picaxe basic or move to a chip with more available resources – a move that would effectively mean the existing sensor mk1’s/prototypes would migrate to crew/monster sensors as they are unlikely to need the full medical system included and wouldn’t need the smaller chips replacing..

That said, when it comes to a medic box/medic system and building it into sensors, then the design is pretty much locked in, admittedly as an option extra/bells and whistle. A thought regarding that I’ve had is to have the medic system including settings for whatever variables – anyway, that’s more something for another post once there has been more thought/discussion about it – what I’m not wanting it to do is remove the chance for roleplay around injuries, and use a medic box more as an ultra-tech or magical healing system to go alongside bandages and duct tape 😊

The coming bank holiday weekend will see the pretty much production power level emitter circuit being tested with a ppg body and 16/14mm lens. Curious to see how the output comes out on that one 😊 Along with the updated sensor for feedback around it’s user-friendliness.


Following that, and given that at the moment there isn’t really a need to change the emitter/sensor code from Picaxe to C as yet, the next stages, prior to publishing the information will be:

• Add two optional inputs to the emitter circuit – 
• one to change between ‘lethal’ and ‘stun’ settings and one to switch between semi-auto and full auto
• 5 versions of the code – 15,30,50,75,Unlimited magazine/ammunition sizes
• “pump action circuit” – basically for those that want to simulate pump action gear, like the Aliens pulse rifle or similar – 
• This would basically be a 7-15 ‘round’ capability that requires a pump action to reset after each shot, then a longer full reload (Probably triggered by holding a reload button and pumping at the same time)

Other possibilities:

Setup mode – basically it uses the Arcturus code to say what the various settings on the emitter circuit are including magazine size, and the various settings – I envisage this being used really only when shooting a ref box for testing or similar, but it would be an idea to include in the basic circuit I think.


Ref or Referee/GM/God boxes would be combined emitter/receiver circuits with displays that allow refs to set sensors and check sensor settings (I.e. zap a sensor and it verbally reports).

A Ref box would be the only way to enable a sensor to take multiple point damage as well, as rather than 2 versions of the code, I feel it would be easier to default to having it disabled, but with the option of enabling it for those that do want to include multiple damage.

Would it leave the possibility for abuse – maybe. But it’s also something I think would benefit from needing a physical connection via say a usb plug/cable to enable so for example, it would not be possible to make an emitter circuit/gun that say in one shot enables multiple damage on a target sensor and on the next hits it with multiple damage when it’s a single point damage game.

It may sound extreme, but I’m trying to cover as many concerns as I’ve been able to come up with as possible.

I also see a ref bax as a method to enable certain immunities (Say to radiation damage) for monsters though this is still in the air – Medic boxes however, could be used to add temporary immunities to radiation damage ot toxin damage – representing various drugs or even full biohazard suits etc.


All still in progress, but the basic level gear won’t be long before I sit down with the documents and try to convert a lot of notes into something legible 😊

update and bookings

As booking for Babylon 5 : Fall of light, game 2 will be opening shortly, I figure a quick update is a good idea:

I'm busily working away in the forge, updated and creating the Arcturus system and updates

It TOTALLY looks like this....

The Mk2 PPG circuit is about ready and has a different output stage to the Mk 1 so the code won't be compatible with the Mk1 circuits due to this.

I'm planning on updating the Mk1 circuits (The  version in the current documentation) code to bring them in line with something planned for the Mk2, as there's a stock of Mk1 circuits out there now.

Updated documentation for the Mk2  PPG's will be published by the end of July all being well.

Baseline sensors will be around the same time.

Medic and Ref boxes will take a little longer as the planned displays with the picaxe are a little limited so I will need to switch to C for these, bar a proof of concept version using the fairly expensive displays setup to be used with the picaxe chips.
that said, I'll likely post the information for the proof of concept medic & ref boxes while refining them for the future.

Mark 2 PPG board size

Revised PPG board

Well.

Given how much of a “shove it in with a big stick and hope” the original PPG boards were...

I think the revised versions are a tad easier to fit in:

Plenty of room now...

Overall progress

So, quick progress update on the Arcturus system. Now no longer Project: Arcturus now the Arcturus Larp Combat System

Feedback & forwards.

Well, I'll admit I'm a little surprised.


I've been working primarily on two things  since B5 - Data transfer and refining the circuits.

WIP & Refinements

Curently, now the Sensors have been updated following the feedback from Babylon 5, I’ve started working on one of the refinements to the emitter circuits to make them a little cheaper (less componants) before fully publishing everything.

It can be summarised as changing the way the signal sent to the IR emitter is generated.

The current circuits, PPG and in-development use an EXTERNAL signal modulation method – this is the easiest to code, but needs additional external componants.

In this it uses the PWNOUT command in picaxe basic to generate the 57.6kHz carrier signal on 1 pin, and the 1800hz “Hit” signal on a different pin. These two signals are then fed into an external AND gate made from transistors and then, (depending on power output desired) fed into a Mosfet to drive the emitter.

For the data signal, it replaced the hit signal output on the pin with the serial data output after 50 mS, using the Picaxe basic command to generate serial data via the software on any pin. Relatively simple and working fine now.

The refinement in development however takes advantage of some of the modules built into the PIC chip that is the core of the Picaxe to output a fully modulated signal on a single pin, without needing the components for the external AND gate – the payoff is it’s more difficult to code.

In a nutshell –

It tells the PWM module that generates the PWM  “carrier” and “hit” signals module to not output to the physical pins

Then tells the Data Signal Modulator to use 2 PWM module outputs above as the input.

Triggering the signal is a case of switching the ”hit” signal generation on or off depending.

For the data signal, it’s a case of telling the Data Signal Modulator to use the serial signal instead of the Hit signal

The part I’m currently working on is the switch between Hit signal and Serial data signal - I’ve got the serial data outputting on the Serial out pin. I need to get it switching off the physical pin output for the serial code and also changing the source for the 2^nd input to the data signal modulator. I’m hoping to have it done by the end of the weekend.

Overall though in the end it’ll be worth it, as while the external modulation is quite simple to code, it is a little more expensive components wise, and this is essentially a refinement to get the costs down