BG1, PRELOAD BG2, PRELOAD

Logic Blog

Analogue Logic 4 - Basics of Sampling & Scaling

Rating: 5 votes, 5.00 average.
Analogue Signal Processing
Divide and Conquer


Part 4 - Basics of Scaling & Sampling



Yeah.... So I forgot to write an intro. No one cares about my intros anyway, right? Exactly. Today has the basics of sampling and scaling, but not in that order. Go:



------------------------------------------------------------------------------------------------------


1.0. Basic Scaling

Just to clarify, when I talk about "scaling" here, what I mean is multiplying or dividing an analogue signal by a fixed value (known as the scaling coefficient). So, doubling or halving the value of a signal are examples of scaling. The key thing to note is that it is an operation that has a single input, so is very different to "proper" multiplication and division, where you you would want to multiply one analogue signal by another.


1.1. Basic Integer Up-Scaling
Scaling a signal up is actually quite a simple thing to do, as long as you only want to scale it by an integer (e.g. doubling, tripling, etc., not multiplying by 2.5, for example). For the example of a coefficient of three (which is a very useful scaling coefficient, as we'll see later):
o = ki
o = 3i
o = i + i + i
Where k is the scaling coefficient.

We simply add the signal to itself k times and that gives us our answer. If your value of k is reasonably large, you may find it's significantly more efficient to find the prime factors of the number and re-express the addition using that. For the example of k = 100:
o = ki
o = 100i
o = (2 x 2 x 5 x 5) i

Rather than an adder with 100 stages, we can instead use 2 two-stage adders and 2 5-stage adders, which is rather a large saving in both resources and tedious wiring.


1.2. Basic Downscaling
Downscaling is significantly more tricky that upscaling and we will cover an advanced method for dividing a signal by a fixed value later, but to begin with I'll cover a simpler method, that is essentially a cheat. However, it's pretty efficient for a few signals, most notably notably those generated by:
  • Player Sensors.
  • Tag Sensors.
  • Timers.
  • Counters.


It will also work for any device where the analogue output is proportional to it's current state, so score sensors etc. will also work. Taking the example of halving the value of a tag sensor, the following graph demonstrates the raw sensor output and the desired / scaled output (click for larger image):



fig 1.2.1. The concept of scaling, with regards to distance-based sensors


Note: I have, for the purposes of keeping the explanation as simple as possible, ignored the 100% region when distance is set to zero (see Analogue Logic Fundamentals sections 2.4 / 2.5 for details). This will technically skew the results of the following, but the principle is sound and if you need complete accuracy including the 100% zone, then you can recover it by playing around with minimum ranges and potentially using a secondary sensor.

Anyway, what we are trying to do is to scale the graph in the y-axis, but we don't have the tools to do so (at least not yet). However, we do have the ability to scale it along the x-axis and we also have the ability to transpose it along the y-axis and if done correctly, for this specific function, it will give us the same effect. For the case of halving, we can achieve it by doubling the maximum radius of the sensor and then subtracting 50% from that sensor output, as shown below:



fig 1.2.2. Graphical Explanation of the solution


It should be clear that the resulting output value is the same as the desired output shown in fig 1.2.1. Of course, as shown by the dotted line, the nature of subtraction means that we could well end up with negative value output, so we use a splitter to discard any value below zero, as shown below:



fig 1.2.3. Sensor Scaling Circuit


1.3. Generalisation for any Scaling Factor
To summarise, downscaling a signal from a tag / player sensor by K:
  • Alter your Max Radius to be k times bigger than you require
  • Shift the value down so that the value at distance = 0 is 100/k. To achieve this. For example:
    1. k=2, subtract 50.
    2. k=3, subtract 66.66 (or 67).
    3. k=4, subtract 75.
  • Split the resultant signal and take the positive component only.


Spoiler Spoiler - GeekNotes: on Proving the Scaling Method



1.4. Downscaling Timer Outputs
The process for downscaling with a timer is similar to the tag sensor, except that the output is proportional to time rather than distance. With that in mind, we scale up along the x-axis by increasing target time. After this it gets a bit complex as it really depends on what you want the timer to do. If you want it to count upwards to 50% and then stop after T seconds then you can simply set the target time to 2T and then limit the signal to a maximum of 50%.

If you want to create a triangle wave, where T rises to 50% and then starts to descend back down, you'll have to trigger that manually, using something like the following:


fig 1.2.3. Triangle Wave Generator with 50% scaling on the output


The timer takes a directional input and the sequencer is acting as a comparator to trigger a change of direction (using the toggle) when the output is outside the range (0% < o ≤50%). Due to the nature of LBP simulation, the period of this device will probably be ever so slightly out, but for most applications will be sufficiently accurate).



------------------------------------------------------------------------------------------------------


2.0. Sampling

Sampling is the act of capturing the value of a signal, at a given moment in time and storing it for future use. Generally, in the real world, it has little or nothing to do with scaling, multiplication or division. But this LBP, which is so very far removed from the real world, and our toolsets are limited. Often we need to take the long way around to arrive at something that our intuition tells us should be simple. In this case, some of the DAC concepts from last time are a precursor to sampling and sampling is, in turn, a precursor to more advanced operations that will come next time.

It's also worth noting that I'll be focussing on timer-based samplers, specifically for the fact that they do lead on to other things and the design concepts behind them are pretty cool, even if they aren't necessarily the most efficient implementations.


2.1. Basic Timer Sampler
The timer, when configured to take a speed input, will integrate the analogue component of the input signal over time, which is a concept best conveyed by example, as going into the details of integration is really well beyond the scope of what we need to know here.

Suppose I have a timer set to 1.0s target time and I feed an analogue signal of 50% into it. The result will be that the timer fills up at half the normal speed. So, at 50% a 1.0s timer will take 2.0s to fill up. Similarly, if you feed a 25% signal into it, it will take 4.0s to fill up.

However, consider what happens if I feed the analogue signal of 25% into it for exactly one second. 1.0s is a quarter of the time needed for the timer to fill, at input strength of 25%. Therefore, after 1 second, the timer will have recorded a value of 25%. This is more than possible to achieve using the circuit shown below (note the relay from last time, being used to enable input to the sampler:



fig 2.1.1. Basic Timer Sampler


It's a bit confusing, so the following is a list of tweak settings. Note that both timers have been dropped to a maximum time 0.1s, so our sample occurs faster. It doesn't actually matter what the values of these are, the important thing is that they are equal:

  • Sample Window Timer (1):
    • Maximum Time: 0.1s
    • Inverted: Yes
  • Sample Data Timer (2):
    • Maximum Time: 0.1s
    • Inverted: No
    • Input Type: Speed Scale



When the sample signal goes high, both timers are reset. The sample data timer will empty and the sample-window timer, because it is inverted, will start outputting a digital 1, activating the relay for 0.1s. The data input will then be passed into the sampling timer for this 0.1s and so it will record the value of the input.

Note that as the sample input is fed into the resets of the timers, this is a digital, edge-triggered input signal.

You can modify the sample window timer to wire into the input and use the "Start Counting Down" input to trigger the sample window. I just think the wiring looks neater this way around.


2.2. Issues with the Basic Timer Sampler
There are three issues with the basic sampler, that limit its usefulness.
  1. The signal has to drop to zero as each sample begins (each sample begins by resetting the sample data timer).
  2. It takes a tenth of a second to complete the sampling. During this sample window, the output must be considered invalid, due to this Return to Zero (RTZ) behaviour.
  3. Taking 0.1s to complete the sample isn't really sampling the signal at a specific moment in time - it's actually taking three samples of the signal during that window.


Spoiler Spoiler - geekNotes: On the LBP System Clock



2.3. High Speed Sampler.
In the 0.1s sampler circuit above, there are 3 system clock ticks during the sample window, so 3 samples are taken. Fun fact: the resultant output is actually the Arithmetic Mean of the input at these three sample points (though again, the details of exactly where the averaging takes place are fundamentally tied to the integral function, which I'd rather not go into). In many cases, this won't be a problem. If you are literally using the sampler to store a signal value for use some time later, then you should be fine. However, there are occasions where this is undesirable and so for those occasions, it's useful to know how to make a faster system. The reason we took three samples in the previous device is that our sample window was open for 0.1s, which corresponds to three system clock ticks. If we can instead open the window for a single clock tick, we can genuinely get the instantaneous value of the signal.

Obtaining this single clock tick frame can be achieved by using a "pulse generator". The pulse generator literally generates a pulse that is the length of a system clock tick. The best way to achieve this is a counter, set to target count of 1 with the output wired into it's own reset. When you increment the counter, it's value increases by 1. 1 is the maximum value, so this actives the output. The output is wired to the reset and so the device resets itself. Conveniently, the system inserts a delay of exactly one clock tick on feedback loops, meaning that the time between when the counter activates and when it de-activates, is exactly 1 system clock tick, so the output is held high for exactly that long, hence our Pulse Generator.

So, we can activate our sampling window for exactly 0.033s, using our pulse generator, as shown:



fig 2.3.1. high Speed Sampler


Note that in this circuit, I'm using an AND gate relay, rather than a microchip implementation, as the counter is guaranteed to output a hard 0% or 100%, so there is no need to use the microchip-activated relay, which is a very useful feature of the pulse generator - it's analogue and digital are both in the form of a useful pulse.

Of course, life in LBP logic is never simple and by shortening the sampling window we've removed one issue, simply to replace it with a new one. Our sampling methodology relies on the timer having a maximum time equal to the length of the sample window. In this case, that is no longer true. The timer's maximum time is 0.1s and the sample window is 0.033s. This results in the stored data is scaled down by a factor of three. However, this is easily corrected by using a simple multiply-by-three circuit, detailed in section 1.1. (I told you multiply by 3 would come in useful - it's almost as though I have a plan... ).



fig 2.3.2. high Speed Sampler with Corrective Upscaling on the Output



fig 2.3.3. Comparisons of Basic and Fast samplers


The above is a comparison of the outputs from the two samplers, both sampling at each whole second. I've swapped the graphing to be a more accurate representation of the signals in the system, than what I've shown in previous blogs. As discussed above, values in LBP are not continuous against time and at this level of analysis it's very useful to actually think of them as updating every 0.033s, which is what gives us this stepped input waveform, rather than a smooth curve.

With the stepped waveforms it's quite clear to see the basic sampler updating over three system clock cycles and how this affects the result. Due to it taking the average (mean) of the three values, the resulting sampled value will be higher if the input is increasing in value during the sample window (like at t=1s) and lower if the input is decreasing in value (like at t=2s).



2.4. Atomic Sampler.
The high speed sampler does update in a single clock clock, but we are still plagued by the RTZ behaviour at each sample point. However, unlike the slow sampler, the characteristic of the fast sampler is to have a valid, sampled value, then drop to 0 for that single clock tick, then immediately back to a new valid value. Therefore, the problematic area exists for only a single clock cycle, at which the output value is known. If we can force the output to a valid value during that cycle, then we can have a perfect atomic sampler using timers.

The sensible way to achieve this is to have a back-up sampler, that will hold the value for that single clock cycle of invalid state. It will then immediately sample the main sampler to take a new backup:



fig 2.4.1. Using a Back-Up Sampler to Create Atomic Sampling


The outputs of both samplers are fed into an OR gate, to obtain the maximum of the two values, which is how the back up sampler is able to hold the output at the previous value.

The back-up sampler is using the simple sampler (0.1s sample window configuration). Generally this is preferable, as it avoids an additional adder tree and as the input (from the main sampler) will be guaranteed to be constant during the sample window. This does assume that your sample rate is smaller than 7.5Hz (as 4 clock cycles are required to update both the main and back-up samplers successfully) but for most sampled applications this is a reasonable assumption to make.

Most important to note is that the update for the back-up sampler occurs immediately after the main sampler. If it didn't then you would hit problems if your new sample were less than your old sample - see the graph at time=3.0s. You can see the single clock tick delay on the update, which is when the back-up sampler is triggered and drops back to zero. If a longer delay is triggered, then the blue dotted line wold continue to hold the output at the previous sample value. We achieve this by triggering on the falling edge of the pulse generator:



fig 2.4.2. Atomic Sampler Circuit


Spoiler Spoiler - geekNotes: On Atomic Sampling



2.5. OR Gate Samplers
I've focussed on the timer samplers here, as they will lead directly onto to some pretty awesome functions as we move forward and there is a whole load of interesting LBP system theory in there for high-speed signal manipulation that is transferable to other advanced logic applications. However, if all you really want to do is a bit of store and recall, the following is actually most likely to be your best method.

If you recall the loopbacked OR gate that is used as a digital permanent switch, the basic mechanism is that the once the output is active, this active state is fed back into the OR function and thus keeps the output active. If we consider this in analogue terms, once the output has reached a specific value, this value will be fed back into the max() function and so the output will never drop below that value. This in itself is a useful function - to be able to store the maximum value that has been seen on an input over a period of time and is another form of sampling.

However back to more normal clocked sampling, let's assume this device is outputting a 0% signal, and the input is at 0%. If we were to pulse a value into it for a single clock cycle, that signal would be output and the output would stay at that value after the pulse, so we have created a very simple sampler. However, there are issues once again. In this case we have sampled a value using a max() function and so any subsequent samples must be greater than the current value, otherwise they will never be reflected to the output. This means we don't have a "proper" sampler, it's more of a 1-time sampler, which makes sense as our starting point was the permanent switch. What we need to do then, is to disable the loopback during the time when we input the pulse, which is achieved like so:



fig 2.5.1. OR Gate Sampler Circuit

In the bottom left is the pulse generator, which takes our sample trigger. When this is triggered it activates the AND gate relay to pass the value of the input into the first input of the OR gate, for a single clock tick. During this period, the loopback is disabled (forced to zero) by the second AND gate relay. This means that the output takes the value from the input.

On the next system clock tick, things get complicated. The counter resets, which swaps over which AND gate relay is active - the main input from the circuit is no longer being passed to the OR gate. But, the OR gate has not updated yet within this clock cycle - it's still outputting the value from the previous tick. This value will get passed through the relay and back into the OR, which will then update, taking a zero from the top relay and it's own, previous, sampled output from the bottom relay.

This loopback will continue to be active until the next sample point at which time the loopback will be broken, in order to "forget" the old value, and a new value is stored.

This device hinges on the fact that propagation within a simulation frame does occur - the AND gates have to update before the OR gate for this to work and the way in which the network is evaluated during that clock tick after the pulse is absolutely critical. As before we never actually see this propagation. It's hidden from the user but it is very real thing, necessitated by the nature of software simulation and something that we can leverage to our advantage.

There are some interesting properties of this device. It's very similar to the atomic sampler above, and for the most part is just a more efficient version. But there are some very subtle differences.

Firstly, it stores both analogue and digital data correctly, unlike the timer devices, which will only store the analogue component of the input, so it is possible to use this as a digital sampler (or D-Type Flip-Flop, if you like). Secondly, it does not insert a delay like the timer based atomic sampler. When you trigger the sample, it will update on the same tick. Generally this is a good thing, I guess, but it does mean that a shift register is impossible to create with this device, as the signal from the input would continue to propagate down the chain instantaneously.


NOTE It's possible this doesn't actually work. Or at least shouldn't work. The nature of correct latency model for LBP2 is not what's currently in the beta and in this case, the correct ordering of events is slightly ambiguous due to the non-trivial loop in the system. Obviously I don't have access to the correct spec and the current beta build is known to be buggy with regards to the latency model. I'll let you know if this device breaks when I get my hands on newer builds.


2.5. Musings on the Nature of Memory
Sampling (and by extension, the concept of system memory) is a significant thing for a number of reasons. Obviously those of you who have done much work with computing, especially programming, will appreciate the usefulness of being able to store, modify and recall data values at will. However, there are some slightly more subtle effects of memory that often come in very handy. Like the ability to predict the future.

Not actually predict the future, in the Nostradamus / Mother Shipton sense of the word, of course. More the general ability to have expectations of what's likely to happen in the future. A good example of this is this is the stock market: Suppose I showed you today's share prices for five companies and asked you to tell me which one to buy, you couldn't do more than guess. However, if I were to show you a graph of those companies' shares over the last couple of months, you would be in a far better position to make a judgment on which is liable to do well in the future, because you have historical data.

Bringing this back to something a bit more significant than stocks and shares... suppose you're making a boss and you want to give it some smarts. So you start by giving it a player sensor that can detect the location of the player, who, at this moment in time, is 50 units away. If the player stays still, that a pretty good range for your normal attack and if he's running away, you can probably charge up the mega-cannon in time to shoot him in the back. But what if he's running towards you? At that kind of distance, you'll still be charging your mega cannon, and thus be vulnerable, by the time he reaches you. In that case you'd be better off enabling the melee weapon in preparation. But then there is no point in getting the melee weapon out if he's not approaching!

So what to do? Well, you could randomise... Which isn't very smart. Or pick one of the four options to be the default fallback, which also isn't very smart. Clearly, basing your assessment of the situation through current state of the world alone is insufficient to make an intelligent decision. But if you knew where the player was a second ago, you could combine that past data with the current data and make an informed prediction of where they are going, thus solving the issue of which weapon is most appropriate.

Our ability to make estimates about what is going to happen next are largely based upon analysing trends - comparing past data with current data to form some expectation of future data. Once we have a model of the state of the future, we can make plans and we can even pre-empt future events. If you are merely going on current data, with no memory, then all you can do is react and you'll always be one step behind. Though, saying that, many animals and AI systems do a bloody good job of producing sophisticated behaviour without the use of memory. So maybe being able to remember stuff is overrated after all....



------------------------------------------------------------------------------------------------------


3.0. Summary
Just so you know, this is half the content I was originally planing on putting into this installment of the logic blog. It kinda spiraled out of control and became a 7000 word behemoth before I was even close to being done, so I apologise if it's full of promise about the apparently redundant timer samplers being really useful for some future things. On the plus side, it does mean that analogue logic part 4 part 2 (which I may well name part 5, because that's the sensible thing to do, unlike the norm in LBP levels) will be coming shortly. Though not as shortly as you might hope, because I still have pictures to organise and Assassin's Creed to play this weekend.

It'll be good though, it features scaling by any arbitrary rational number, 2-operand multiplication, 2 operand division, and real-time differentiation.


.

Updated 11-25-2010 at 02:39 PM by rtm223

Categories
Logic Blog

Comments

  1. Octus's Avatar
    Well.. TBH.. I've got no freakin' idea about what u wrote..!
    But I can tell it's a great effort..
    Is there a link u can slap at me that can help an egnorant creature like me?
    I'm really willing to be a big creator in LBP2
  2. Sehven's Avatar
    Good stuff. You lost me from fig 2.3.3 to the end of section 2.4. No idea what those graphs were showing or what you were talking about there.

    The whole time you were talking about timer based sampling I was wondering why you weren't using the OR gate sampler, but I guess, as you said, you'll explain that later.

    The division process seems a bit cumbersome (extending the range and so on) but I suppose we work with what we have. Any ideas on how to divide an analog signal from a thumbstick or sixaxis? The best I was able to come up with was a positional sequencer with a ridiulous number of batteries at 2.5% intervals (actually 2% and 3% intervals alternating) hooked into an OR gate. Rather than actually dividing, it was just triggering whichever battery was in range and using the percentage that I had previously assigned. It worked well enough but was a pain to set up and doesn't give perfectly smooth transitions (though it was for a camera system and you don't really notice 2% jumps in a camera).

    The idea of memory is intriguing. As I understand it, you were talking about a simple system for tracking whether the player was moving toward or away from the boss at the given time, but I imagine it could be extended to actually track the probability that the player will charge or retreat from a given position: to adapt to the player's fighting style. That could be pretty cool, but I'm sure it'd be a huge pain to build.

    I've been tinkering with the idea of a radar and it occurred to me from your talk about the boss knowing where a player is, that a radar could be built that could pinpoint the exact position of a player or tag on a display screen by combining a direction vector with a percentage of signal strength. The direction would be most easily achieved by a narrow sensor (<5 degrees) doing a sweeping motion and either capturing the time of the detection (via sampler) or by building an identical sweeper to into the display. It would actually be pretty easy to implement (though I imagine it would require a sequencer with a series of batteries like I described for my rudimentary divider) but the thing that still stumps me is the actual display: you wouldn't want to make a full pixel display because then you run into framerate issues with having so many small items on screen so it would need to be something along the lines of a vector graphics display... but how to implement such a device? Emitted dots? That doesn't work if the display is attached to a moving hud (the screen moves out from behind the dot). I think I'm starting to get off topic, so I guess I'll shut up now.

    Thanks for all the info.
    Updated 11-21-2010 at 08:56 AM by Sehven
  3. Gui_Rike's Avatar
    My head... It hurts!
  4. Rogar's Avatar
    Best one yet! Also, this explains why the arms of my sackbot were jittering when I tried to make a controlinator recorder; it was dropping on the return-to-zero! But maybe I'll give it another shot with what I learned here...

    One nitpick: for the atomic sampler you say you use a basic 0.1s sampler as the backup to save on an additional adder tree. But couldn't you simply put the OR gate before the adder tree?
  5. Amigps's Avatar
    I have no idea what all this is saying. I have to learn what all the terms mean because that's what lost me.......
  6. alexgangsta4's Avatar
    Well, that is one short blog...
  7. rtm223's Avatar
    Sehven: I was a bit concerned about those graphs, if others are having issues with them then let me know and i'll rejig it with some extra annotation and stages. I think I might have ****ed up in that bit because the sampling graphs just make sense to me but im not explaining them well to others
  8. phort's Avatar
    Rather than having a backup sampler on your atomic sampler, why not just return the input value for that one frame using a relay?

    Wouldn't this eliminate the 1-frame delay as well, making it (possibly) the same as your last example?

    Other than that, nice job! Very useful resource.
    Updated 01-22-2011 at 03:49 AM by phort
  9. rtm223's Avatar
    Yes, you could do that, which is actually quite a nice little method
  10. phort's Avatar
    I figured out how to continuously divide a signal by an integer! What do I win?



    The timers on the left have their max time set to (the integer you want to divide by) / 10. I'm dividing 100% by 3 here, (timers at 0.3s) and you can see on the sequencer that my output is 33%.

    I took inspiration from your sampler, but used two timers that are constantly resetting so instead of taking an input to take a sample when I get an input, I can sample continuously, and output from one when the other is resetting.

    I feel like somewhere in here there should be a way to multiply by a large number besides repeatedly doubling it to do a sort of binary-style addition system.

    Edit: Also, are you planning to do more of these?
    Updated 01-24-2011 at 09:58 AM by phort
  11. rtm223's Avatar
    snap :




    I have full text for the next installment, it's missing a couple of pics though, so I'll get those done and publish ASAP - especially as you're stealing my thunder with your working out how to do the stuff I'm trying to teach you before I get chance to teach you it


    Edit, not quite snap but close enough, the principle of the two samplers in parrallel is the same thing


    In fact, looking at your version, it occurs to me that the AND gates are completely redundant - you don't need them at all, I think we've both just added them because they feel right, but if you take them out I'm almost 100% sure that it will still work. Scratch that - it won't work at all. But prefixing or postfixing the AND gates around the timers makes no odds, both designs work on the same principle and both are perfectly good solutions, just stylistically different
    Updated 01-24-2011 at 11:03 AM by rtm223
  12. phort's Avatar
    Do you know if there's a good way to handle overflow when you add past the max/min? I'm multiplying a signal such that the result can be greater than 100, and rather than clamping max value, it apparently starts to decrease. I'd like it to clamp to 100% instead, but I can't think of any way to handle it.
  13. rtm223's Avatar
    If you use the adder techniques in my earlier blog, then they re-route overflow into additional adder circuits (and encode overflow into multiple wires). If you just wish to discard overflow then you can just leave those negative outputs unconnected and you will add the inputs with a ceiling of 100%

  14. Shanghaidilly's Avatar
    I've tried building your timer based sampler and I think I have it working. But it's not storing the sign of the signal, just the magnitude. Is this what you're seeing? With the retail version of LBP2, I'm seeing some different results than you've outlined here in these pages - the combiner, for instance never returns the sign of the signal. I'm using Balorn's probe, and his tutorials don't agree with your findings. I just need to find out who's right and I realize that most of this is based on the beta, not the retail version. Do you have any updates? Thanks for your work btw.

    Update: I took a totally different course of thinking on this and I have it working perfectly. LBP2 is so different than standard electronics it makes you think of thing in a totally different way. Thanks again for providing me the foundation to get this to work.
    Updated 02-03-2011 at 02:55 PM by Shanghaidilly
  15. Shanghaidilly's Avatar
    BTW, found a very strange anomaly when dealing with controllinators. Drop a timer and set the input for forwards/backwards and hook up the left/right output of one of the joysticks. If you get in the controllinator and press the stick to the right, the timer will start to fill. If you release the stick, the timer will stay where it is.

    Now, make a very small change - when hooking up the joystick to the timer, drop the wire on your circuit board to create a node, then hook the node's output to the timer. Should be the same, right? It isn't. Now when you press the stick to the right the timer fills up, but when you release the stick, it empties. ANY circuitry introduced between the joystick's left/right output results in the resting position of the stick to result in a NEGATIVE output value. It's also strange that a probe still reads the output as zero.

    To say the least this was driving me CRAZY! ...and still is.
  16. rtm223's Avatar
    Yeah, I noticed this in the beta and reported it.

    The ternary digital signal with a proper 0 state is only used by the directional-type inputs and there aren't many sources that can produce it (analogue sticks, 3-way switches and combiners are the only ones that spring to mind), so it's a little bit less of an issue, but it is incredibly annoying that the nodes break it - as they should be null components. As far as I can tell this concept only exists because of backwards compatibility with the 3-way switch (arguably the combiner was partially invented to replace 3-way switch logic.

    Guess it's too late for this one to be fixed... guess it's time to find a use for it instead
    Updated 02-03-2011 at 09:14 PM by rtm223